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Peperasnce has Shewn that the traditional methed of 


software development often has poor results. Recently, 2 
new approach <o)606d sCftware development, z=he  psotectype 
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I. INTRODUCTION 

Current software engineering practices re based ona 
develcpment model which is 10 to 15 years old., This model 
is often referred +o as the waterfall model. The waterfall 
model shews the development of software as a series of 
discrete steps [Ref. 1, 2, 3, 4, and 5}. 

Experience indicates, however, that software development 
is net as discrete as the model indicates, soc the mcdel has 
reen efined by adding loops between each of the steps. 
Furthermore, as software maintenance has gained recogniticn, 
there is increased pressure to refine the waterfail model to 
Show the added importance of maintenance inthe software 
life-cycle. 

The software engineering profession's concern abcut 
software maintenance, which is more properly termed refine- 
ment and enhancement, has orompted several conjectures. 
Deo fret. 20] haS suggested that the current cycle of 
develcp, izplement, refine and enhance, implement, refine 
and enhance, implement, and so on is really che construction 
and refinement of a prototype systen. 

Several other authors have suggested that we should 
develcp software protctypes as an alternative to the tradi- 
tional, On watertaen, approach ‘to software development 
(Ref. 68, 236, 62}. Dneveeoriaczpal argument is chat the 
process cf software development is really iterative, slowly 
expanding toward a ccmpleted system. Other reasons include 
enhanced communicaticns between the usar and designer, fewer 
requirements problems, quicker turnaround between initial 
system need and initsai system implementation, to name a 
few. 
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The precess of developing a software prototype hés 
Beqneticant intuitive appeal for users and managers; they 
can +try a system cut before committing themselves to a 
system which is either unsatisfactory or undelivered. Aside 
from this appeal and the benefits often cited, there seems 
to be little discussicn about the principles underiying the 
development of software prototypes. 

This thesis presents cne view of how the process of 
develcping software rrototyrpes supports some basic eiements 
of general design theory and software design specificaliy. 
Chapter II develops an integrated set of désign c¢iements 
based cn several published models of the general design 
process. Chapter III relates these design elements tc soft- 
ware develorment by citing examples from the computing and 
information science literature. The purpose is to show that 


software design is similar to other fields of design.! 


Chapter IV introduces the software prcetotype. The 
process of developing software prototypes, «heir roles as 
Medeitsc, Ccnstruction etrategies, and the principal us 
protctypes are descrited. The chapter concludes by shcwing 
how protctyrpes support the design elements from Chapters II 
and III. Chapter V kEriefly describes the essential features 
cf scftware engineering environments, especially ‘hose 
features which are needed for developing software proto- 
types. Chapter VI presents four case examples which illus- 
trate tne process of developing a software prototype. These 
cases were chosen because in each of them there was an 
explicit decision to use prototypes. Ehapeens. Vilvand VILi 
present Conclusions and Recommendations for Further Study. 


{fo faraphrase Gertrude Stein 


Design is design is 
design is design. 
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II. MODELS OF DESIGN METHODS 


ee eat SS a ee SE SSS 


A. STRUCTURED MODELS OF DESIGH 


The ideas about design and design methods hav2 undergone 
some significant changes in the last 20 years. The early 
models placed their emphasis on the process of design. 
These mcdels had a rational, discrete notion of design in 
woich the design precess was thought to be a sequence of 
Weml-defined, highly structured activities. Many theorists 
applied tke ideas and principles of the scientific methced +o 
the process. Alexander [Ref. 6] was one of tne earliest of 
the design theorists +o carefully explain design. His three 
most significant contributions were: 

1. The symmetry cf the design problem--that is, design 
has two symmetical parts, the form (the soluticn to 
the problem) and the context (tne setting which 
defines the prcblem). ee Sdapvarson- 25 a mutuel 
phencmenon referring to the context's adaptaticn to 
the form as much as the form's adaptation to it's 
GEnccxt “Seetwetne) design problem is an effort to 
achisve "fitness" between the form and it's context. 
[ Ref. 6] 

2. Tke formal decomposition of a set of requirements 
into successively smaller subunits. 

3. The importance of diagrams in design. A diagram, for 
Alexander, is "fa ]jny pattern which, by being 
abstracted frcem a real situation, conveys «he rfhys- 
ical influence of certain demands or forces ..." 
(Ref. 6:3 p. 85] 
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Alexander chose tc é@mphasize the process cf dececnpos*ion 
in his early work. This process was divided into two 
phases, analysis and synthesis. . 

In analysis, the designer, faced with a problem, derives 
a mental picture--often vague and unsatisfactory--of the 
demands of the context, and then d3composes that picture 
into sets (a mathematical picture). Synthesis begins by 
developing diagrams (tased on the sets), using the diagrams 
to form a design, and then deriving the form (see Figure 
weet) « Alexander also discussed evaluation {he calls it 
"goodness of fit"). Goodness of fit is determined by cne of 
two criteria, experimental or non-experimentai. Ths expéri- 
mental criterion is triai and error where "{tjkh¢e experiment 


Mmmoicceing a prototyre form in the context itseif is th 


D 


eae Critericn of fit." [Ref. 6: p. Pe sb Syrohe— 
experimental critericn is "{aj] complete unitary description 
of the demands made ty the context ..." [{Ref. 6: pe. 21). 
Alexander believes that: 1) trial and érror is too expensive 
and too slow and 2) there is no theory which can express 
meee a Unitary description of the varied phenomena of a 
Baet2cular context." [Ref. 6: p. 20]. For these rteascns 
ke concentrates on the process cf decomposition. ? 


Alexander's structured view was shared by many theorists 


Guring the early 1960's. (Ref. 8, 7]. Archer (Ref. 7] 
thought cf design as @ goal-directed activity. The goals or 
cobjectives cr the prcklem define che propercies required in 
eve Sclution. The details cf the design are the designer's 


decisions about how te implement those properties [Ref. 7: 
pe 286}. 


2Alexander devctes an entire Appendix to the 
"Mathematicai Treatment of Decomposition." 
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Figure 2.1 


Alexander's Design Phases. 
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Archer identifies three components of the d¢si 
Process: 

1. The advance through the project and through time; 

Zee fhe Eranching cf the problem into its logical part 
and, 

3. A preblem-solving process cyclically moving throu 
Sukproblems (using a 30-step reiterative operation 
mcdel). 


Jones [Ref. 8] called the three stages in his view 
the design process divergence, transformation, and conve 
gence. He was quite convinced that designers should thi 


cf these stages as séfarate: 


mecnere 1c itttle deube that their Separation is prere- 
qGuisite to whatever changes of methodology are necessary 
at each stage before they can be rein<egrated to form a 
Sati i that works well at the systems level. [ Ref. 8: 


Pe 


BP. WICKED EROBLEMS 


These early models were often criticized. Ore erigen 
that design problems are "wicked problems" and a 
iysis 


d 
meme, therefore, ameéneble tc structured ana (and decc 
cn) 


Class of social system problems which are ill- 


formulated, where the information is confusing, where 
there are many clients and decision-makers . with 
eonflicting valués and where the ramifications in the 
whele system are thcrough ly confusing. {Ref. 9] 


Wicked proklems have the following properties : 


1. Wicked problems ae ili-formulated. They have 
definitive formulation and any formulaticn wi 
GceuespOndmecucie LOrMmUlation or the solution. JG hel 
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means that any time a formulation is made, additional 


ais) 





questions can be asked and more information can be 
reguested. This also means that the information 
needed to understand the problem is determined by 
one's idea or plan cf a solution. In other werds, 
whenever a wicked problem is formulated there must 
already be a sclution in mind. 

Wicked problems have no stopping rule. Any time 4 
eciution is fermulated, it could be improved or 
worked on more. One can stop cnly because one has 
run cut of rescurces, patience, ¢tc. (An architect 
cculd keep modifying and improving a d¢sign solution 
ferever-~he stcps because ne has exhausted his fea, 
because the kuilding has to pe finally built, One 
because he has exhausted some other resource.) 
Sclutions to wicked problems cannot be correct or 
false. They can cnly be good or bad. (There is no 
correct or false building: there can only be a "“gocd" 
Buaidand (cCeman Dace. bul iding. ) 

In solving wicked problems ther? is no exhaustive 
list of admissable operations. Any conceivable plan, 
strategy or act is permissable in finding a sciution 
and nene can be perscribed as nandatory. 

For every wicked problem there is @iways mers «han 
cné possible explanation. The selection of an ¢xpila- 
hation depends on the employed world-view; the ¢xpla- 
Naticn also determines the solution to the problen. 
(The high cost of construction of a buildina may be 
attributed to the “expensive" design, tc the high 
ccest of materials, to the wages demanded by unions, 
tc high interest rates and inflation, etc.) 

Every wicked problem is a symptom of another "higher 
level" problem. (If the maintenance of the residence 
is "too expensive" tc its inhabitants, this indicates 
that there is a problem with *he income of its inhab- 


means S.<. ) 
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7. $\No wicked proktlem and no solution to it has a defini- 
tive test. In cther words, suo? esha geese ae 
"successfully" passed it is still possible that the 
sclution will fail in some other respect. (If large 
windows are designed for a residence to provide the 
desired views, the heating of the residence may 
become too expensive.) 

8. Each wicked preblem is a “one shot" operation. There 
FeevecmnOOn £OEmmtrLal and error, and there is no 
Eoecsibidity 7 fcr experimentation. (A housé is 
designed and built--there is no going back to the 
beginning to redesign and rebuild it.) 

9. Every wicked froblem is unigue. No two probiems are 
exactly alike and no solutions or strategies icading 
<c solutions can readily be copied for the next 
DECD Lent. (Even if two residences are designed for 
the same family, under the same geographical ccndi- 
tions they will never be identical.) 


mere. 6S 


mo, The wicked problem sciver has mo 61g 


| 


REchG=-heliceeuely ©Fesponsible for his action. 

If design problems are considered as wicked problems, 
they are certainly incompatible with the early rcdels of 
design. The sarly mcdels clearly separated the problem fron 
its solution. With wicked problems, one cannot "define the 
problem"--they have no definitive formulation. TE Jone 
foilowed the procedures of the early models cf design, one 
should ke akie to establish when a solution was .cieéarly 
found. Wicked problems, however, have no stopping rule. 
some cf the propcnents of the early models of design devised 
tests for design solutions. Alexander argued that trial and 
Seror shculd eventually lead to "good fit"; unfortunately, 


each time a soiution is tried, the problem is also changed. 
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C. ACCUMULATED KNOWLEDGE MODELS OF DESIGN : 


Other design models were proposed following «he criti- 
cisms of the early, structured models of design. Rae ce | 
(Ref. 13] views the whole design process as sequential 
problem solving in which the cycles form networks. An 
essentiai part of this model is the continuous feedback 
between tke designer and the problems environment. Rac 2 en 


calls this ‘argumentation': 


me -_- ene designer [is] arguing toward a solution with 
himself and with cther partiss involved in the project. 
He builds a case leadir £9 a petcer understanding of 
What is to be acccmplished. imtoo  COUrse, Solution 
principles are developed, evaluated in view of their 
expected performance and decided upon. The parties 
commit themselves to specific courses of action and to 


the risks involved in them. les Bae betrer formu- 
daticns of th2 prceklem are being developed simul«ane- 
Susly with a clearer and clearer image ofr the solution. 
fRef. 13 3: pw 19- 


If argumer=<s are improved procedurally, tneizr content may 
improve and the PEOaduccs OG the d2sign--design 
decisions--may also he expected to improve. While ‘argu- 
ing', che parties may gain aew insights about “he issue, 
expand skeir world-view, modify challenged positions, nd 


learn morse about other world-views. 


2. Eatsstns in Essign 
Alexander introduced the GONe=sptesot Eero ra 1 
diagrams in design in 1964 (Ref. 6]. Saqniricant ily, 


Alexander believed that the design diagrams were produced by 
formal, rigorous analysis, a design process founded cn math- 
ematical decompositicn. Since then, Alexander and cthers 
[Ref. 10} have concentrated on the diagrams (cr Patterns) 


Tather than the process. 
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Alexander's fatterns are not a result: of rigcercus 
analysis. Rather, design is a process of acquiring knowl- 
edge and then making decisions which reflect that knowledcae. 
The crucial issue for Alexander is the availability of 
knowledge. That is, the design decision depends on the 
accumulated knowledge of the designer. Patterns help to 
provide tke designer with the necessary knowledge to solve 
the problen. The pattern forms the basis of communication 
ketween the designer and the client. A pattern--a diagram 
of what the designer knows and believes important for the 
problem--is designed and then passed +0 tke cliént. The 
client either accepts or does not accept th2 pattern. In 
@elther case, beth the client and the designer gain new 
knowledce: if the fattern is not accepted, the designer 
proceeds to change the design. 


3. Desiqn as Learning 


Fazianac [Ref. 15] views the design process as 
formulating the rroblem and proceeding with a search for the 
Meeeda-icn cf the solution. He emphasizes that the forztula- 
meeon cf the problem is not final. The formulation reflects 
the understanding of the problem, based on the designer's 


knowledge, at that time. 


See eae ee. is already basically détermined by the 
Wetinztion Of =he croblem. So the “search for scoluticn" 
1s then the search for the definition of the specific 
solution which best fits the knowledge the designer has 
at that time. Cnce the specific solution is defined 1t 
1s documented. Documentation may start during the defi- 
hiticn cf the problem and continue . SOS heh ae during 
fm dEfInition GE che soilution--in fact, al three 
phases may at times take piace simultaneously. . The 
ultimate purpose of the dccumentation 1S tc communicate 
the definitions of the problem and the solution; its 
lmmediate purpose is to aid the designer in the defini- 
tion cf the preblem and the solution--to help him detect 
new aspects of the problem and the solution and to 
detect inconsistencies in his view. [Ref. J 


19 





During the search and redefinition, the designer 
keeps learning more akout the problem and the soluticn. MThe 
designer gains new insights which ultimately lead to a new 


view-~ redefinition. The process (formulate the pretlen, 


tn 


search fer the definition of the solution, document the 
specific solution) is repetitive. The designer continués to 
re-define and document new formulations until 1) the incre- 
mental gain in knowledge becomes insignificant and cannot 
change the formulation enough to warrent redefinition, 2) 
the incremental gain becomes too costly, or 3) the designer 


exhausts availabie resources (especially time). 


— a a ee eee 


As the designer and user learn more atktout the 
problem and as the sclution becomes clearer, more and more 
design decisions are negotiated (Ref. 13, 15]. Since these 
design décisions are reached through compromise, they cannot 
be called oftinal, in the sense of management science and 
operations research. 

Simen [Ref. 14] has introduced the idea of satis- 


ficing tc describe these kinds of negotiated decisions. 


Necrmative economics has shown that exact solnticns to 
the large optimization problems of the real world are 
Simply not within reach or sight. In the face of this 
complexity PicsGceemene=e CO DUSinesSs firm turns *¢e¢ proce- 
dures that find gccd enough answers tc questions whese 
best answers are unknowable. Vela oon a Sat lS 
ficer, a perscn whe accepts "good enough" alternatives, 
not because he prefers less to more but because he has 
no choice. [Ref. 14: p. 36] 
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D. 


DESIGN AS A TECHNOLOGICAL ACTIVITY 


Cross and others [{Ref. 16] have proposed a view cf 


design which requires the explicit acknowledgement of the 


organization's role in design. 


'Techncliogy’ ... clearly denotes more than, just hard- 
ware, and involves, at the very least, censideration of 
the or anizational 
designed, | commissioned, operated and wieatd © fer. 
‘Technological’ achievements, whether those of buildin 
a wajer bridge or futting a man on the moon, are as muc 
fag atone t feats as technical ones. (Ref. 'Gc eee 


systems within which machinery is 


These cecnsideraticns lead to thelr view that a "“satis- 


factory" definition cf technology has the following charac- 


teristics: 


1. Technology is criented toward practical tasks. 
2. Téechnelogy relies on different kinds of organized 


knowledge, of which scientific knowledge is cnly one. 
Craft knowledge, design knowiedge, and organizaticnal 


and managerial skill are others. 


eee fLechnological activity takes place in an crqaniza- 


ticnal context. [Ref. 16: p. 198] 


Cross and cthers devcte a great déal of space t9 


highlight the difference between knowing "what tc do" 


(scientific knowledge) and knowing "how to do" (design and 


craft knewledge). Their main point cannot be ignored: the 


organizaticr olays as large a role in design as does the 


mas vidual. 


Ee 


DESIGN IS EVCLUTICNARY 


The early mcedels of désign were frequently criticized for 


their linear, step-Ey-step view of design. Page {Ref. 11] 


warned that the design process is not executed straight from 


analysis te evaluaticn: 
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meesitl the Majority c£ practical design situations, 2 
the time you have preduced this and found out that an 

made a synthesis, you realize you have forgotten <*9 
analyze scmething ¢ise here, and you have to go around 
the cycle and crodtce a modified SENS S28: and so on. 
In practice, yeu ge around saveral times. 


Ellinger stated that the iterative approach to design "... 
is paricularly suited to novel projects of some complexity." 
(Ref. 12: p. vil 

Smithies [Ref. 17] has suggested that there are a number 
of essential stages in design. The first stage, design 
analysis, is the statement cf the problen, Pe The next 
cage censists of finding cne or mors tentative solutions, 
1S. This sclution is then criticized, C. When tne designer 
Criticizes the scluticn, he or she admits tnat the oreblem 
statement was inadequate. Sen the designer re-states the 


problem and begins anew. 
F1-TS1-C1-B2-.. Gk 5 5 


Smithies attributes his views about design to Pcpper 
fRef. 18}. Pooper relieves that «he process or activity of 
understanding can be represented by a génaral scheme of 

zoblem sciving by cojecture and criticism. Popfer's 


scheme, adapted py Srithies, is this: 
ler obs 


mieis the initial ctreblem statement; TT, the 'tentative 
mmeory*, is the conjecture. EE, ‘error elimination?, is the 
critical examination of ‘the conjecture. P2 is the new- 
problem statement which emerges from the examination. oe 
leads tc ancther attempt, and soon [{Ref. 18 : p. 164). 
Smithies' design stages and Popper's problem-solving scheme 
are very much like Folya's {Ref. 19] methcd for solving 
problems. Software designers shculd take note: Polya is a 
Mathematician, Popper is a philosopher, and Smithies is an 
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acchitect, yet zach approaches the solution to a preblem ina 
the same way. ; 
The progress of the designer through these stages is 
marked ty increased knowledge and shifting prioritiss. 
Clearly that progress is not linear and should be called 


evoluticnary. 


Fo. SUMMARY 


Several points about design have been made in th 


iD 


proceeding sections: 

1. Design is symmetrical and adaptive; 

meee The interesting (i.e., large,complex) design freblenms 
can be considered as wicked problems; 

3. Ccemmunications with the end user are cruciai and 
depend to a large degree on patterns which bridge the 
communications barrier between designer and end user; 

4. Desicn isa learning process--each party brings a 
different perspective +o the problem (and the solu- 
ticn!) and leaves (or should leave) with an augmented 
perspective; 

5. Design is satisficing; 

6. Design takes clace in an organizational context; 

fe besiaqn 1s evceluticonary. 

araticn of these ovoints should not be misccn- 
strued. ach cr these aspects is interrelated and to0a 
certain extent mutually dependent on one another. When we 
Say that design is evclutionary, we also imply that design 
is symmetrical and adaptive. When we say that design is an 
organizational activity, we also imply that there will be 


extensive ccmmunicaticn during design. Whenever 


= 
D 


i VEO 


ct 


understand the probdblen, 40 learn mor2 abcut our tentative 
solution, we are raising a problem of understanding, or 
posing a higher levei problen, Which implies that design 


rroblems are wicked froblems. 
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This interrelated set of design elements forms the kLack- 
drop for the remainder of this work. The following chapter 
presents evidence frem the literature that each of the 
design elements described above is a factor in software 
design. 
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III. SOFTWARE DESIGN METHODS 


Aw SOFTWARE DESIGN IS SYMMETRICAL AND ADAPTIVE 


Several instancss in the HLterature _poine <6 the 
symmetry cf the software design problem. That is, the solu- 
tion not only depends on the probien, but the prcblem 
depends cn the scluticn. Solution and problem are net sepa- 
rate issues, rather they are intertwined, much like the 
figure ard cround in a painting or picture. Each depends on 
the cther. Unfortunately, most people associated with soft- 
ware design do nct afprreciate this point. Peters points cut 
that software designers complain bitterly that requirements 
are poorly defined while customers and analysts often 
complain that the design is not responsive to the preblem or 
problems as they see then. (Refs. 23° 3 Deol. Dec ers 
wasn't tke first to recognize this, though. Podolisky wrete 


(nN 


a humerous article in 1977 [Ref. 24] where he states "Peor? 


Law"; 


Peer's Law 


The solution tc a problem changes the problen. 


Several cther authors {Ref. 25, 26, and 27] have also recctg- 
nized that the froblem definition tends te evolve as the 
desianers try to bound the problem, or modify the require- 
ments. McCracken and Jackson (Ref. 27] have gone so far to 
Say that this dependence is analogous to the Heisenberg 
Bian ciple: Any system development activity inevitably 
Changes the environment out cf which the need for the systen 


arose. 
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Much effort is currently devoted to requirements defini- 
tion and yet inccmpleteness, ambiguity, and poor definiticns 
in requirements documents are often pointed +o as the fore- 
most preblems facing software designers today. The effort 
which is spent on completely specifying the user's require- 
ments will gain nothing if software design is adaptive. 

McCracken and Jackson believe that systems requirements 
can never be stated fully in advance. To assert otherwise 
is to ignore the fact that the development process itself 
changes the user's perceptions of what is possibie, 
increases insights into the applications environment, ard 
often changes the environment itself [Ref. 27: p. Bis 
Peters says that although requirments may have been very 
fixed at the beginning, they tend te change and evolve with 
time. Hi £60F no Other reason, the user's percepticn cf the 
Froblem changes as dces the designer's perception of that 
problem [{Ref. 23: p. 70]. 

Change is inevitable during software desian, and yet 
“planning fcr change" has long been given lip-servic2, at 
best. Neumann believes that planning for change is slowly 
being reccgnized aS an important énd in itself--and cne that 
usually cannot be achieved by retrofits into an inflexible 
design (Ref. 28]. 


Be. DESIGN IS SATISFICING 


Mest computer system developers wili immediately argue 
enas point. Developers of military systems would argue the 
longest and hardest. Why should the idea of satisficinrg be 
so controversial? Perhaps the answer lies in +«he past, when 
Machine time was expensive and computer memory limited. 
These limitations do not exist at the same level today. In 
fact, satisficing scccurs all the time. Conn states that the 


requirements for state-of-the-art systems are often scaled 
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dewn tc respond to the need to cut the overall expense of 
the project or to meet time limitations [Ref. 26: p. 403]. 
Designers are, or sheuld be, constantly aware of the trade- 
effs that are made in systems development, especiaily the 
classic trade-off, ccst versus performance. 

Several authors point out that a user should, in fact 
must, sacrifice an cptimum design for a design which can 
cope at a satisfactory level { Ref. 29, 30j. John Munsun has 
keen guotéed as saying: 


Erst look at the economics involved in automation 
as a scftware-rroductivity solution. If a user can ktuy 
a ayrcll program that is almost what he needs for 
$10,000 cr one that exactly fits his needs for $1 
Mailiion, he must look at the trads-offis and reduce his 
expectaticnus. [Ref. 30 :; p. 66] 


Bacaisficing has to do with more than economics. 
Lawrence Feters has said that the trade-offs for execution 
efficiency and ease of change must be evaluated and a 
compremise made. [Ref. 30]. Lockett emphasizes the role of 
usez Satisfaction when evaluating trade-offs. For her, user 
Satisfaction is not based solely on the functional capa- 
bility of a system, but on useability, Geltability, and 
performance as well. Tecsneehe —USSE Cansot have everything 
(for example, both performance and functional capaoility) he 
er she wants ina system. The final product may bé the 
result of ccmpromise. Certain functional cavabilities may 
te eliminated to achieve specific performance jyoals or, on 
the cther hand, tke user may be wiiling to sacrifice 
performance to obtain some functional capability [ Ref. 31: 
pa 15/}. 

Several cther atthors emphasize the role of agreement, 
concensus, and négotiation (Ref. 32, 39, 33]. These2 authcrs 
contend tnat as system design progresses, alternatives ere 


proposed and evaluated. The exact definition of a system 
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may nct ke aS important as the concensus on the inexact 
Meetnition which is attained. An example from Land serves 
to illustrate the importance of satisficing in softwars 


design: 


° 2_¢ « the designer has to be aware that building flex- 
ibility into systems can also be expensive, beth in 
terms of design effort and operational performance. the 


designer is involved in a rade-off between the extra 
development and operational costs, of designing a systen 
which is adaptable and flexible--a very general 
stem--or of designing a very specitic system dedicated 
the needs existirg at the time of implementation, tut 
ich may be incapakle of modification, and may have tc 
replaced if requirements change. [Ref. 29 : p.j 67] 


Satisficing may also involve psychological trade-offs as 
well as technical trade-offs. Madnick and Donovan relace an 
instance where two pessible algorithms could have been used. 
The inefficient algcrithm was chosen because the designer 


could not stand the suspense of waiting [Ref. 22: p. 491}. 


C. SCFTWARE DESIGN IS A WICKED PROBLEA 


Herst Rittel has suggested that design probiems are 
wicked problems [Ref. 13, 9]. These problems are ill- 
formulated, have confusing information, have many clients 
and decision-makers with conflicting values, and have rami- 
fications in the whole system which are thoroughly 
confusing. Peters and Tripp have suggested that software 
design is a wicked preblem. They believed that a comparison 
of the attributes and problems associated with software 
design and the characteristics of wicked problems make it 
apparent that software design is itself a wicked precblen 
[Ref. 37]. A review of the properties of wicked protlems 
and their relation tc software design shculd help tec put 


this neticn in perspective. 
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Wicked froplems have ne de itive formulation. Any 
time a formulation is made, additional questions can be 
asked and mcre information can be requested. Oe raps lity 
to define system requirements completsly and unambiguously 
is a symptom of this problen. Current efforts in software 
develcpment seem to be aimed at the symptom rather than the 
Froblen. 

Several authcers raise the possibility that a complete 
set cf requirements is impossible, that a state-cf-the-art 
system is almost by definition cne for which there remains 
some degree of uncertainty at the ‘time requirements are 
prepared. Under these conditions, it is hard to imagine a 
set ot "“ccemplete" reguirements, since the knowledge cf the 
eventual system at that point can only be incomplete 
{Ref. 26 ; pe. 403]. 

Wicked problems have no stopping rule. Any time a solu- 
tion is formulated, i+ can be improved or worked on tore. 
Cne stcts cniy becaus2 one has sun out cf resouces, 
patience, cr something else. Few would argue that thers are 
clear stopping rules fot software design. (Else why are 


there innumerable exampoles of cost and scnedule overruns? 


They can enay oe @ecae Of bad. PArsS NOtL~Onacan Ee quate 
contreversial among computer scientists. Granted, a 
computer system must work properly, especially in life- 


critical cr life-threatening circumstances (hospital equip- 
ment or nuclear reactors, for example). But Nwork Proper. y' 
has different meanings to differant people, or groups of 
people, just as do "correct" or "true",3 ’ 


discusses the idea of “truth", an 
Xx Great Ideas, Macmillan Publishing 


3Mortimer J. Adier 
alco wees yes 
19872. 


idea we judge bys 
So., inc., New crk 
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Perhaps "good" and "bad" are poor choices as well, yat 
most of us readily acknowledge the differences when 
presented with "gocd or bad, HoLemwnom ¢\! The distinction 
could be thought of in terms of ‘technical success! and 
'psycholcgical success'. Technical success is the degree to 
which the actual performance of the system matches its spéec- 
prmcaticn, while psychological success is the degree to 
which the end user has confidence in th* final system 
{Ref. 36]. 

Ancther distinction can be mad2 from the observer's 
point of view of a system: a system exists ana is defined 
by tke perscn(s) observing it. It is as acceptable, pethaps 
even laudable, as the observer perceives it to be. Ifa 
System works in the eyes of those who use it, then to these 
users that system is a good one. Conversely, if a svstem is 
cbserved aS not working by those same users, then it is not 
good recardiess of any cther attribute it may have. 
meet. 33). 

In sciving wicked problems there is nO exhaustive sist 


of acmissablis operaticns. Any conceivable plan, strategy, 
or act is p¢ermissablée in finding a solution and none can be 
prescribed as mandatory. Anyone in the profession can see 
that this certainly applies *o software desigr (granted, 
there are at present a finite number of "design methcdolo- 
gies", yet each year this number continues to increase). 
The literature is replete with rererences to design methcd- 
clogies: cbject-oriented design, data-oriented design, 
design based on finite-state machines, and so on. 
See Table I for a large, and certainly incomplete, Il:ist of 
design methcdologies. 

Not only are we faced with many alternatives fcr a 
design "methcdolcgy", but we also are facad with innumeratkle 
alternatives fer solving the subproblems in the particular 


design case at hand. Theres may be more than on@ way i 


Hea 
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TABLE [I : 
Cesign Methodologies 


= | 

nhemenic Full Name of Methocology | 

M/PCM Active and Fassive Compcenent Modelling 

eS Data Crienteéed Design { 

SAD Bas Structured Systems Analysis and | 

esign 

SD Data Structured Systems Development 
M Evolutionary Design _Methodclogy 

ES Gradual Evolution of Information Systems | 

= Higher Order Software ee 

Pros FP Adaptation of IBM Federal Systems Division | 


Software Engineering Practices 


SN NWNNHNHNNHNSAYN HA HW AMAwO UCU Ix 
WO BF WHtUOrPUrrHMnN MW tM WOKNOM NeN 


iv 


taticn of Information Systems 
User Sortware engineering 


CS i as ys SS as Ec RR i al Ei Al A) I ll ci — i age OA i TS OO. th Cs: PS 


SM Information Engineering Specification | 
Methcd | 

AC Informaticn Systems Work and Analysis { 
of Changes | 

c Jacksen System Development | { 

AM Nijssen's Information Analysis Method | 

EL Structured Analysis & Design Technique 

RA System ARchitect's Apprentice | 
System Developer |. | 

mo LC Structured Analysis and Structured Design | 

M System Development Methcdology . | 

EN software Engineering Proceduras Notebock 

EM SO eae Reguirements Engineering Methc- 
0109 ; 

RADIS sTRuctured Analysis, Design and Implemen- 

| 


: 
| 
| 


which a target system develcpment process can proceed simply 
because there are alternatie approaches available at the 
time the requirements arz written. A decision between these 
alternatives may not be possible [{Ref. 26 : p. 403}. 


possikle explanation. The selection of an explanation 
depends cn the perspective, or world-view, used. The expla- 
haticn also determines the solution to the problem. (For 


example, the high cost of software is often attributed to 
labor-intensive design and programming; poor requirements 
definition is often Elamed for software "failures".) 
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Ne wicked preblem and no solution to it has a definitive 
test. In cther words, any time any test is "successfully" 
passed it is still fossible that the solution will fa 
some cther respect. This characteristic of wicked fr 
is tied very closely to the idea of satisficing. Lf 
computer systems are Euilt to be flexible, their design must 
ke generalized. The aspect of flexibiiity is gained at the 
expense cf efficiency (not that this is bad!). So, the 
system "passes" the test for flexibility but is very ineffi- 
cient. 

Each wicked problem is a “one shot" operation. There is 
no rocm for trial and error, and there is no possibility for 
experimentation. Many large-scale computer systems have 
this characteristic. In fact, software development is sone- 
times compared +o building a bridge--once it is built there 
is ne gcing back to the beginning to redesign and rekuild it 


(for any number of reasons). 


FT} 
tts 


y wicked prceklem is unique. No two problems are 
Wao Ke anagem evo | SOCLU2ZOnhS OF Strategies leading to 
soluticn can readily te copied for «he next probien. af 
teristic is very evident in software design. Military 
systems, for example, are certainly unigue. Commercial cr 
industrial problems are no less unigue. Each organization 
has a unique structure, set of goals and objectives, set of 
interaccicas with the environment, cast of people, and set 


of needs. * 





The wicksd froblem solver has no Eight to be wrong -- 
he/she is ZEully respcnsibie Zor his/her acticn. There has 
been a grcwing skepticism among users regarding the ebili- 
ties cf secftware designers. Users have every reason to 
believe that *he software designer "knows" the job. 


*Note that what is béing discussed is the ovérall 
Frobien, not a subprecrtlem. Th? questions about reuseabdility 
and software components should be directed ONLY +0 subpgreb=- 


lems, tor ckvious reasons. 





Clearly, tke designer must be aware of many of the factors 
which could affect the design. The designer must also be 
aware cf the effects of design decisions. Allowances will 
and can be made for unusual unforeseen difficulties. But to 
hide behind the "This system meets the specifications you 
approved and signed" statement 1S going (and has gone) too 
ee bae 


D. COMMUNICATIONS BETWEEN THE DESIGNER AND THE END USER 


Perhaps the single, most widely noted problem area in 
software design is the problem of communication between the 
user and the designer. The récent literature emphasizes the 
need for extensive ccmmunications [Ref. 25, 29, 30, 35, 39, 
and 40]. The most common reason given for the preblem is 
that users and designers speak with different vocabularies 
and find it difficult to completely understand @ach cther. 

Much of the literature which cites the need fer closer 
communicaticn is based on empirical and ancedotal reperts. 


King and Rodriquez [ Ref. 41], however, report an assessment 


of participation (and communication) in svstem development 
in an expstimental ccntext. The experiment tested fcur 
specific hypotheses (see Table ITI) about participative 


design which were stated in null form.5 
The ¢xpéerimental results (see table III) indicate that 
participative design makes a difference, especially when 


viewlng the "worth of the system", 


Mee ini= | cmly means chat the ‘claim', i.8. “accepted 
w-sdcm" in systems design, was set up as the alternative =o 
the hypethesis, 3n accord with traditional  aypothésis 


testing. 
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H3: The substantive inputs provided by participants in 
the design process will not be reflected in their usage 
cf the systen. 
HY: Tke decision performance of participants in the 
design process will not be different from that 
or NCN=farticipants. 

Crecente cee cee ee ee a A OE ES A ES TS AE SD SS ED ND SS ED STE 


, 
| 


a 


TABLE If 
Hypotheses Tested in the Experiment 


H1: Farticipation in the development of the system has 
no effect on the user's perception of the worth cf the 
system. 


H2: Farticipation in the development of the system has 
no effect on the amount of us¢ which is made of thse 

eae ce? when the user is faced with strategic issues for 
which the system was designed to provide Support. 


gs ee een em cen om ey CE RE ee, RS SED ot, CRE oc SE eae EEE RE oe EB 
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TABLE LEE 
Results of the Experiment 


H1: The null hypothesis is rejected. 
This result indicates that panagers who are involved in 
the develcpment erfort tend to perceive the system to 
be more worthwhile than managers who are merely given a 
pre-designed system to which they had no input. 


wes .Cannot a Be the null hypothssis. 

conclude that the use of the system in terms of number 
of queries 1s not significantly different for d¢sign 
batcl@cipeantsS and nen=participants. 


ee Se a OE a ee ee ee Es ee oe ee ee 


Ho: Whe null 2 a ate was rejected. 

1* indicates that the substantive 2 Sear provided by the 
participant group in the design and development phase 

of the information system are reflected in their 

actual use of the system. 





H4; Cannot reject the null hypothesis. 


| 
| 
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As King and Fodriquez put it, the 


Mees 5 GXperifient frovides some support for “particira- 
Save Gesign theory"; (a) The inputs provided by partic- 
Bee cs appear to have been made use of in their use of 
the system, and (Fr) Some positive attitudinal impact-- 
in terms of systems “worth"--seems +o be achieved 
threugh participaticn. {[ Ref. 


The experiment seems to confirm some deeply held convic- 
tions that participation in, and responsibility for, design 
implementaticn can result in elimination or reduction of 
communicaticn problems [Ref. 29:3 p. 65]. 

Ther may tbe scme reason to oelisve that the real 
problem with communication is not whether it takes flace but 
whether tke media of communication is appropriate. The fact 
that the designer has produced a comprehensive specification 
and that the user has ‘signed off' che specification after 
due study, iS not a guarantee that the designer has under- 
stood the user's needs, or the user the designer's specifi- 
@araon fkef. 29 : p. 65]. Stucki has suggested that charts, 
Seapnics, color pictures, and other aids should be used to 
enhance communications between users and designers; verpal 
descripticns alone are just as inadequate for describing 
software as they ar¢ for an architect building a hcuse. 
fRef. 30}. So, althcugh communications may be a significant 
problem, its form may be equally as important. 


E- SCFTWARE DESIGN IS LEARBING 


Software design is learning, just ask any experienced 


program mtanager. They want someone with design experience 
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to head the design team [Ref. 46}. Sp -nOuUete eX CLicitly 
acknowledging it, these managers place vaiue in the experi- 
ence learned from previous work. This “learning from 


doing" also takes place during the design of a system: 


The reason for the discovery aspects of software design 
is the designer's learning curve. As the _system is 
studied, analyzed, and a design formulated, certain 
features are reccgnized as needing attention while 
others are overlocked. . As .1t becomes See which 
features are lacking, priorities shift. [ReE. 37] 


If we accept that learning is an element of design, just 
how important is learning to design? In an experiment, 
Alavi and Henderson {Ref. 55] evaluated two strategies for 
systems develcpment: evolutionary and traditional. BY 
their definition, the evolutionary strategy emphasized the 
role of individual learning. They reported that the find- 
ings supfert the hypcthesis that an evolutionary iapleméenta- 
tion strategy is more effective than a traditional strategy 
fRef. 551. 

meey =cy te explain their findings this way: 


A model which cffers an explanation for the findings is 
Kolr's experimental learning model [see Pligure Se ale 
Kolk suqgests that for a learner to be effective ne/she 
must have the ability to engage in four types of activi- 


ties: (1) rnvelverent in néw, concrete experiences, (2 
observaticn and teflecticn of these experiences, 3 


creation cf cencerts that integrate these observations 
inte tkeories, and (4) usage of these theories to make 
@ecisicrse and solve problems. + » « The ¢voiutionary 
Sesategy meps directly with @ starting point at concrete 
experiénces. icon tLract, Pie cuca neromal | approach 
began with the development of a ede | e « « An expla- 
nation cf the findings may rest in the support that the 


evoluticnary strategy had for the ioscan process. 
meRref. 55 } 


This model has some important implications fer soft- 


ware design. For example, the perspective or world-view 
that the designers (ard users) bring to a project beccme 
important (after all, we are starting from concrete 
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Figure 3.1 Kolb's Learning Cycle Model. 


experiences). Greenspan and others believe that the ability 
to efficiently design appropriate computer systems and 
enable them to evolve over their lifetime depends cn the 
extent tc which real world knowisdge can be captured 
{Ref. AI}. Wasserman (Ref. 35] takes the thought further by 
Suggesting that memkers of the different groups ccncerned 
with design perceive the function of an information systen 
differently. Misunderstandings of objectives can and do 


occur, many times leading tc project failure. 


37 





Land [{RBef. 29} also states that there ars different 
ideologies and cerspectives among che different interests 
involved in a systems study. Land suggests that managérs 
m2et this challenge by setting up a design team which 
contains representatives of ail the major interest groups, 
making i+ possindle fcr the different ideologies and ¢f£3 
tives of the particifants to be made explicit, a 


d 
different members of the group to Jléarn fErom each 





different viewpoints {Ref. 29]. 

Hew wight the farticifation of users in the systan 
design enhance or premote learning and real-world knowledge? 
Robsy [Ref. 42] conducted an experiment that explored 4 
model of constructive conflict in the MIS desvelcrpment 
process.’ His mcdel (presented in Figure 3.2) is descrited 


here: 





Meer GCarticipation should lead to conflicts, which 
sheuld then ba Satisfactorily resdIived. However, 
@emtlict and its resolution are more 12 a cOmeOG Cle 
when users can exercise their influence in the develcp- 
Mem. frcczss. Seyelece leseslts aces not iecad to its 
MmeaelUutTzon; cather the increase in conflict makes reolu- 
tion more difficult. heats OUMy ca sGOUGh Dabelc2pas2On 
and influence that conflicz can be successfully resclved 
in this model. [Ref. 42 
There is other research Which supports Rotey's 
Meonsctructive conflict". Boland {Ref. 54] compared two 


different processes cf interaction in system design: 
1. txraditional--the designer conducts a traditional 
interview of the user 


2. alternative--the designer and user share ideas, 
present mutual suggestions, aniwwecr league “their 
suggestions. 


His results are significant: 
ced higher quality 


1. The alternative orccsss produ 
tavion advantages. 


designs with important inolemen 


3s 
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Eaqure 3.2 A Constructive Conflict Model for User Involvement. 


Ze The two prcecesses produced designs Which used 
different organizaticnal control strategies. 

3. Different precesses may help to define different 
problems and *hereby produce different, but equally 
rational, solutions. [Ref. 54] 

Boland likens the prctlem sclving process to a dance durinag 


which tke designer punctuates his interaction with the user 
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Gea Series Of teaching, suqgesting, and critiquing.® 
Foland asks wus *0 accept the notion cf learning and <¢ 
importance cf real werld knowledge: 


Let us accept that the viewpoint and implicit models 
held ty designers will color their collecticn and inter- 
pretaticn cf data about the needs of the organization 
they are designing for. This study suggests that under- 
Standing how tka viewpoint buiids a coherent design 
statement BegULT 2S an understanding .cf how the designer 


interacts and exhanges information with his client. The 
MmueeracCtlon proetoccis nay then be seen as mediating the 
Beeces= cf completing ‘the designer's “point of view" 
(creating the désign Statement). {Ref. 54: p. 896) 


Rebey*s experiment lends support to Boland's findings: 
"It appears that participation does lead to perceived influ- 
ence in .. . system development” (Ref. 42}. Robey's find- 
ings suggest that influence is used constructively to 
resolve conflict and that users learn how ‘*o exert infiu- 
ence towards conflict resolution as weli as conflict genera- 
tion as the development process proceeds [ Ref. 42 3 p. 82}. 

As we have seen, there is support that learning, argu- 
mentation, ang a ceSianer's world-view are isgpertant 


elements in software design. 


Fe. SCFIWRARE DESIGN HAS AN ORGANIZATIONAL CONTEXT 


me first glance, the casual reader is apt to say "You 

ere stating the ecbvious." Yet much of the current work in 

software design igncres the obvious. Land provides scmne 
evidence for this: 

1. Users are uncertain about the affect the final system 

will have on their individual roles in the crganiza- 


ticn and cn them personally. 


SCcmpatre Boland's “dance" and Robey's “constructive 
Setieiacco' —tCe SOftware design to Rittel’s "argumentation" in 
design (Charter ITI). 
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2. The cbservaticn that the user operates within fcrmal 
systems and that the formal procecure cf the existing 
systems have keen overtaken by less formal (but cften 
mere effective) unauthorized procedures. 

3. The fect that those who are involved in the analysis 
precess-~-DP specialists and users--are often not 
aware of strategic decisions made by senior manage- 
ment which cculd have an important bearing on the 
werkability of the system. 

4. New systems almost certainly include innovations; 
users and analyst/fdesigners cannot predict managers! 
responses to innovations. Conjectures abcut peorle'ts 
behavior are no substitute for knowledge, and in 
innovation, such knowledge is not ordinarily avail- 
able. (Ref. 29: p. 64] 

Althcugh Land cited these points as reasons for communi- 
cations rotlems, they can equally serve as indictments 
Begia@ast current software design. That iS, organizatioral 
meee ts Cf ccftware cesign are often ignored. 

Wassé€rman points out that organizations and computing 
envizrcnments are highly dynamic and that information systems 
must bk¢e designed fcr a changing organization [Ref. 35]. 
Chafin states that as computer systems become more deeply 
involved inthe operations of organizaticns, they have 
larger s¢ccial effects on these organizations. A new 
computer system may change the organization structure, ‘tne 
power structure, or the overall information flow structure 
in an organizaticn [Ref. 40}. 
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Zmud and Cox reccqnized the organizational asrfects of 
software design in their discussion of a “change" approach 


to design and implementation: 


The change approach to MIS. implementation strives to 
create an environment in which change will be accepted 
through the active involvement of affected oryaniza- 
tional members an intensive educational program, and, 
most importantly, the assigning of project resfonsi- 
bility to the MIS user. Additionally, a sense of mutual 
trust and committment must develop between participants 
so that a free exchange of beliefs and opinions is 
possitle. [{Ref. 53 : p. ] 


Zmud and Cox make no reference to wicked problems, yet 


their change process is reccmmended when (1) +the organiza- 


tional activity involved is ill-défined, (2) the MTS must 
interface with other organizational systems, and (3) 
substantial organizational change is exrected. Cecmpare 


these characteristics to Horst Rittel's characteristics of 
wicked protlems (Chapter II). 

Althcugh there are several articies and references to 
rganizational aspects of software design, two authors stand 


cles, 


}4- 


cut. Kling and Scacchi have writtan two extensive art 
{Ref. 59 and 60j, which stress the need for an awareness of 
and attenticn to organizaticnal and social aspects of systen 
design. Their latest work [{Ref. 60], develops a family of 
models (called web mcdels) which they pelicve helos tc "make 
tetter predictions of the outcomes of using socially complex 
computing developments", These models are contrasted to 
‘discrete-entity'--rational and traditional--models. Their 
work attempts iO abstract a set of DrEanciel cs, 
characteristic of wek models, from analyses published in the 
literature 
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Kling and Scacchi stress the importance of perspective 


in the 


"social analyses of ccmputing". They identify six 


perspectives, four of which predominate: 


Hes 
oe 
a. 
GQ, 
Their 


Formal-rational 

Structural 

Interactionist 

Pclitical 
pcint in discussing thes? perspectives is that each 


"Casts a different light" on the significant aspects of the 


design problen.? 


Further discussicn of the work of Kling ma SeGacchz 1s 


keyond tke scope of this work. The point to be made of 


their 


work is that software design is conducted ia an crga- 


Nizational framework: 


In contrast te the discrete-entity nodels, Which gain 
weeps rt caity oy ignoring the social context of computing 
developments, web models make explicit the sali¢nt 
conections between a focal peo shells abe) Shorea lil rebeltel 
Meaatical contexts. f Ref. 60 : p. ; 


G- SCFIWARE DESIGN IS EVOLUTIONARY 


MUcCh Gf the EWFsent practice in software desig 
iG 


constrained by a model populariy t¢rmed the ‘wats 
u 


model. 


TOM GtlE epcty SUMS up *he attic 


ware professionals: 


It seems that they recognize, as y 
ite cycle. in particular, they s 
a revclutionary lif¢ cycle (i1xk3 t 
as c 


the 


—_— eae oe oP 


*Kling and Scacchi present an extensive di 
the sccial dynamics. cf system design in {Ref. 5 
discussicn iS based cn the four pérspectives no 
weli as two others: human relations and class po 


Fcosed toa mcre evyclutionary 
evelopment of the human species 


Dm aba =P ae «<> aan a «<= 
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MeleneaucnoGe alee complain about the current life cycle 
model. Brittan is cencerned that the serial definition of 
the project development cycle, known as the linear strategy, 
embodies cne fundamental concept: that an activity follows 
logically from its predecessor so that each stage is 
complete kefcore the next begins [Ref. 36]. McCracken and 
Jackscn seem to be the most critical of the current life 
cycle model. They bEeliev2 that any form of life-cycle is a 
project management structure imposed on system déevelcpment. 
meee neragcre, they fecint out that the current life cycle 
model is either a very much simplified mcdel (which is 
worthless) or unrealistic [{Ref. 27]. Podolsky [Ref. 24] 
argues that the current model (which he terms Classic 
Development') is "very, very good" when it is successful, 
but that when it fails, Mac’ s heerid". He attributes the 
success and failure cf Classic Development +o the type of 
problem which will be solved: classic development 1s good 
for well-defined, highly structured, change-resistant preob- 
Meme, it tails when oresented with an ill-defined rreblen, 
changing Ccmeca pants, and changing requirement 
Zvegintzov {Ref. 57] has two objections to zhe current li 
cycle mcdeél. Parsu, it does not portray a systems life, 
only the creation, development, or youth of a system. se 
do@#s net include adulthood and is vague about operation and 
Maintenance. S=cond, feels NOs Gecyele, lk SOLELEayYS 3 
linear path and does not, as a cycle must, ZeruLn yee 2ts 
beginning [Ref. 57]. Gladden even goes so far +o say that 
the software life cycle may be aarmful to the softwares 

rofessicn. See Figure 3.3 for Giadden's representaticn. 

These arguments, and others, begin to raise a question 
about che validity of the linear strategy. The linear 
strategy places a great deal of reliance on the studies and 
efforts made in the earlier ‘'stages' of software develop- 


ment. Yet this strategy ignores the fundamental aspects of 
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Pigure 3.3 
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design déscribed in Chapter If. Beier raieeolaces 205s 

predicament in persvective: 
In a majority cf cases, particularly when the organiza- 
meen  crestcnSible for designing an implementing the 
Syscem has experience of similar systems and when the 
users are, clear about what tney want, the iJinéar 
Strategy is pefectly satisfactory and produces gcod 
reguits. Too often,. a preject starts Sn the linear 
Strategy but the initial requirement is vague, over- 


ambiticus or fails to meet tke 
requirement is still fluid. 


eeries of shcrt 


in a 
Ref. 


meres, « « « 


Now it becomes clear why 
3.3 appears as it does. 
ware design, 


strategy. That is, 


the practice 
to proceed in a 


real need: in fact the 
The project then preceeds 
locps as the réquirement solidi- 


Gladden's representation in Figtre 
To make up for the reality of soft- 
“QO use 2 


WS 'eCoOpy Linear 


series of relatively 


haphazard and short-term locps. Again from Britta 


Qs 


Some leops are inevitable. One of the Symptoms Oe 
excessive loopzness isa feeling of antipatny between 
mee different greups associated wit the project, 
Particularly 1= “they are geographically dispersed (the 
we/they syndreme) ;the svstim esiqners wistl qrumtbis 
about users never knowing what they want and users aill 
be anncyed by the aprarent lack of good project manage- 
ment as the System cverruns its budget in both time and 
cost. [Ref 36] 


Brittan gives other reasons why the linear strateg 


1. when analysts refine the requirements of 


their investigaticns and studies frequentl 
rroblems which were not suspected at the ou 
be 


investigations made Ly analysts; 


+he linear strateqy can oniy based on gs 


users, who 


=he success of the systen, are not usuall 


the conjecture and exzrapolation needed tio 
these studies. 

Land (Ref. 29], Brooks [Ref. 46], 

{[Ref. 32}, and Lehman [ Ref. 47], 


argued that a system wiil require 


Podoisky [{ Ref. 


to name a few, 


Substantial, 
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VuaS spo cz: 
a systen, 


Yeenit cw Up 


tset. 


tudies and 
determine 
y adect at 


understand 


24), 
have all 


Lave 


cortinuing 





changes after the client begins to use the systen. W 


(D 
ct ct 
x mM 
Eee 2 
#7) per) 


tc reiegate this phenomenon to ‘Maintenance’. But 


isa't encugh. Consider this comment by Land: 


e conventional mcdel of the systems life cycl? assumes 
at an analysis and feasibility Ses precedes the 
tailed design stage and that tnis will be followed by 
Ss 
€ 
1e 


(iD Do 


pecificiaticn and agreement of the specificaticn for 
systen. At that point the design of the system is 
en frozen. For atypical information system the 
ages preceding the design freeze take between 20% and 
35% of the total time required for the develoment cf the 
System. Fer betweer 65% and 80% of this time the design 
of the system is not_to be modified, eéven thceugh «he 


WO ct uct e3 
cro 


Bmorlda™" is changing all the time. [In Practice, ¢ven a 
frezen design géts modified if the system is seen te be 
beccming irrelevant <o real Sie cues: Sou. ean, 
inccnsistencies in design are iscovered during. the 

S a 


construction BRGIEIC as a resuit of "systems queries! 
{ Ref. 29 : p. 68] 


Scftware design, nce matter how hard we try otherwise, is 


Simply net linear. The literature clearly supperts a3 


+ 


fu 


evoluticnary strategy, yet our practice has not recognize 
eS 
H. SUMMARY 


The preceeding discussicn shows that there is support in 


the literature for reassessing our view of software desig 


3 
8 


Software desiqn is symmetrical, but we currently do littl 
to recognize that symmetry. Software design is satisficing, 
yet there is constant emphasis on optimization, Stren for 
its cwn sake and forsaking approaches that enhance th? 
useability cr quality of the softwares. Perhaps, withcut 
conscicusly noting it, we aze also concerned with the "test" 
design and dooming the project to mediocrity, a* best, and 
perhaps catastrorhe. 

Software design, especially for large-scals systems, is 
certainly a "wicked problem." All the evidence is there; ir 
cnly remains to ackncewledge that fact. #e are well awars 


that communications between the designer and user are 
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mer impcrtant. Yet, we have not really given much theught 
to the medium of exchange. Software design is a learning 
experience. Designers learn that projects are more complex 
than expected and users learn never +o trust designers. 
This may ke a harsh critigue, but the point is wali illus- 
trated: all parties gain something from the experience of 
software design. Let us recognize the worth cf this. 

The organizational context of software design has long 
been igncred, particularly in military systems. We must not 
forget that the computers are to help the people in a systen 
mompertcrm well, not to control the people as @ part of the 
system. Finally, we are beginning to recognize that soft- 
ware desiaqn is evoluticnary. hiere tealiev= 1s no Mend! so 4 
project, simply a restatement of the goals originaliy iden- 
mom.ed. 

Although seven characteristics have been stated and 
discussed, their interdependencies are obvious. None of 
these characteristics is mutually exclusive of another. 
memeeert, ack buzids ¢n the cther. Although thers ar¢ innun- 
erable implications in that statement, the remainder of this 
work will examine one approach which may help us to consider 


the sever characteristics or design in software design. 


48 





A. INTRCCUCTION 


For the last 35 years, systems software develormrent has 
teen based cn the sScr-called ‘system development cycle.' As 
shown in the last chapter, there are several arguments 
against such a cycle. Perhaps the most telling argument 

2es in cur process controls. Several authors [Ref. 61, 
62] have pointed out that in response to uncertainty and 
increased ccmplexity, there is a tendency to define and 
structure (and increase!) Management ECn=rols. 
Corréespendingly, preéecise requirements definitions have be¢en 
emphasized. Berrisford and Wetherbe ({Ref. 61] believe that 
there is a major conceptual flaw in the traditional view of 
systems development. This is that system design assumes 
that management knows what information is needed and it is 
@ernticult, if nct unrealistic, to ask managers tc define 
their infcrmation requirements on paper. 

Hew de scftware designers cope with *his vroblen? et egal 
and Waters (Ref. 63] have explored this question and 
theorize that scftware designers cope with complex design 
Froblems by using several mental tools, one of which 
involves simplifying assumptions. The use of simplifying 
assumpticns is both necessary and commonly used when 


constructing large and complex systems: 


Given a_ccmplex programming problem, expert programmers 
a choose simplifying assumptions which, though 
faise, allow them to arrivé rapidly at a program which 
addresses the important features of the problem withcut 
being distracted by all of its details. he Se ieee Seba 
assumptions are th¢en incrementally fetracted wit 

Beno Ang modiricaticns to the initial progran. Often 
the main questions can _be answered using only the 
initial pregram [{Ref. 63 : p. 150] 
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This use” of simplifying assumptions in software design 
is very much like the idea cf the tentative solution, - which 
was introduced in Chapter II. Such a tentative soluticn is 
only a simplified system. Earl (Ref. 64} calls these 
Simplified systems frototypes. Carrying this one step 
farther, Naumann and Jenkins define a prototype syst2m as 
"a system that captures the essential features of a later 
systen." {Ref. 62]. The sections which follow will 
describe tke prototype process, the role of pretotypes as 
models, the ways in which prototypes are used and ccncludes 
by showing how the set of seven desing elements are 


supported by software prototypes. 


Be THE PROTOTYPE PRCCESS 


The terms frotctype and prototype systems have beccne 
rather ccmmon lately, found in both the management litetra- 
ture (Harvard Business Review, for example) and the scftware 


engineering literature (oroceedincs of conferences and work- 


shops especially). Althcugh the term prcetotype has beccme 
standard, early descripticns of the process were calied 
"heuristic development" and “iterative 2nhancement" 


{Ref. 61, 65}. 

Regardless of how each of usS may use the term, there is 
general agreement that the main purpose of prototype systems 
is 2xploretion and experimentation; "the aim of the sazly 
Beetotyps Js to Jsarn, to find out, to discover." [Ref. 66, 
64, 66]. In keeping with their purpose, protctypes are 
relativeiy inexpensive, flexible, and Simplified systems. 


Bally, Brittan, and Wagner describe the prototype proceass: 


ie cae ERECtOtCYPS Strategy, an initial and usually highly 
Bee pa teers pro EN erson of the system is designed 
lmpiemented, tested and brought intc operation. as¢ 
on the experience gained in the operation of the firs 
prototype, a revised requirment is established 
secend Bae Y De designed and implemented. The 
repeate as cften aS is necessary to ac 
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Satisfactcry oferational system bearing in mind the 
Pesci bly esCaleting cost of each Subsequent cycle; it 
may weli be that orly one prototype is nessasary befcre 


prcducing the final System. [Ref. 683 p. 


Frem this descriftion, four steps are evident [ Ref. 62}: 
1. Identify the user's basic information requirements. 
2. Develop a working prototype. 
3. Implement and use the prototype. 
G&. Revise and enhance the prototype. 
Figure 4.1 illustrates the prototype process. 

A pretotype system must be implemented quickly, oerhaps 
in hours or days, certainly no more than two or thrze weeks. 
The advantage here is in the user-designer int¢ractions: 
the user is given a working system to operate and criticize, 
the designer recéives responses based on the user's expeari- 
ences. The quick response of the designer guarantees that 
the first prototype will be incomplete. This aspect is 
important: there ls an explicit understanding bétween the 
user and desianer that the system will be incomplete, that 
a prototyre is meant *¢ be modified, expanded, supplemented, 
Seecsurtrlanted [ Ref. 62]. 


Cw. PSBOTCTYPES AS MOPELS 


Many authors consider prototypes to bé models (Ref. 64, 
Be, 69]. As nodels, prototypes reduce risk and test altér- 
native designs through live operation. [{Ref. 64]. 

Three aspects of prototypes as models are important. 


First, models are abstract: 


me Critical skill cf system design is .. , claimed tc 
be .¢xplicaticn of the implicit models in _managers' 
minds, of their decision-making processes and views cf 
their crganisation and environment. [Ref. 64 : p. 163] 
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Figure 4.1 The Prototype Model. 


Second, managers prefer simpie mod2ls at first. As they 
begin to understand the models, they become involved with 
the design and implementation +9 build more realistic 
systems. [Ref. 64]. 

mao, a prototype is subject to modelling effects. 
That is, as a model, the prototype is only a limited version 


of the final system. SO, a prototype is one kind of scale 
model, accurate in some ways, inaccurate in others 
(Ref. 69}. 
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De. STRATEGIES TO PROLUCE PROTOTYPES 


Three strategies are generally recognized for producing 
protctyres, 1) methodologies (in current use), 2) executatkle 
specifications (state-of-the-art and research issues), and 


3) autcmatic program@ing (a research topic). 


1. The tMethodolegy' Strategy 


There are three basic methodologies which are used 
to produce software prototypes. First, in screen ard repcrt 
formatting, the designer produces a set of user interfaces 
which will be similar +o the final system. Second j;ain 
partial ard incomplete implementation, the designer and user 
identify cnly a subset of the total problem. sWaiatasfol cose 
selective irplementation, the designer develops components 
of tke final system and then integrate the components. 
(Ref. 71] 


2. xecutable Specifications 


See Se ere la a 


The executable specification, tne second technigue 
meme rOcctyring, iS a current ‘hot' topic in tke com 
Science literature. Davis [Ref. 72] describes a scf 
cool, the Feature Simulator, Which “executes" fo 
writter teguirements specifications for real-time ak 
Feather [Ref. 73] fEroposes a methodology for deve 
protctypes from specifications based on the transformation 
See "Specification eonce <r ucts" Into an implementaticn. 
Perhaps the most ambitious work on executable specifications 
is that reported by Cohen and others. They believe that "a 
protctyrpe serves to mitigate both imperfect communication 
and lack cf forsight (sic)." [{Ref. 74] 

The solution Cchen and others have adopted s¢parates 
the imperfect communication and lack of foresight issues by 


having a fcrmal specification language which unambigicusly 
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describes systems, anda separate tool (symbolic execution 
system) which helps the reader to understand any particular 
specificaticn. This tool can be used by the specification 
writer tc validate the specification and by the impl¢ementor 
(o> buyer) to understand what exactly has been specified 
(i.e., hew the pleces interact). "Given the specification 
and the tool, a prototype will not be needed." That is, if 
the designers can ccmpletely specify the requirements and 
they then use the symbolic execution system, Cohen and 
others believe that it is no longer useful to develcp a 
EBeocOtype. 

Fut consider tne follcwing comment by Taylor and 
Standish: 


: .. Peeag a precise specification ZOE Ge =O enc 
e Since the user really doesn't know what statements 
ake in sucha language-- that is, he can't articu- 
his needs 1f he doesn't know what they_are regqard- 
of whether or not there is a precise languagé for 
ing them. (Ref. 78 : p. 160} 


WU HFct Dore 
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Executable specifications clearly are controversial, 
especially when they concern prototypes. Whetner sucha 
technique gains frominence will depend oon advances in soft- 


ware engineering tools. 


3. Autcmatic Preqramming 


Automatic pregramming is probably farther away, 
technically, than tke exscutable specificaticn. Automatic 
Frogramming can be thought of as programs that help peorle 
write prcgrams. The general goal of autcmatic programming 
is tc allow the software designer +o think cf the problem 
aestractly, ina way which is natural and comfcrtable. 
Autcmatic programming systems are characterized by spec:ifi- 
cation methcds (formal, 'by exampie', or natural languagé), 


the target language (the language in which the system writes 
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the finished program), the problem area (area of interded 
applicacicn), and the method of operation (theorem-proving, 
program transformaticn, kKnowledge-engineering, or tradi- 
tional preblem solving) {Refs 100]. One advantag= cf auto- 
Matic prcgramning is that it could allow Cua, MOTE 
informality than an executable specification language 
(Ref. 70}. 


Eom USES CF PROTOTYPES 


Generally, there are three uses of prototynes, 1) +0 
clarify user requirements, 2) to verify the feasibility of a 


design, and 3) tc create a final system. [Ref. 75]. 


eeeec da cteyecuesiser ts Reguirensnts 


Ey far, the most popular use of prototypes is t 
eacify the user's requirements. MeCrack=n f Ref. 6 


bridge <he communications gap between tha desiqnez> and ti 


+ 
relieves that traditional written specifications do no 
h h 
user. He states that protctypes encourage us g 
their minds about what they want, until the system is 
useful. 
Tc higniight the problems encountered in require- 
ments dccumentation, Mason and Carey (Ref. 76} make a 
distincticn among three tyves of documentation: 
1. A textual list of requirements (*he most ccmmonly 
used) 
2. An interpretive model (gaining in popularity, eésre- 
cially in military systems) 
3. A working modél--a prototype 
The textual mist, the traditional methcd of 
describing requirements, has a distinct disadvantage. There 
is a psychological distance bétween a textual list and what 


the users will eventually receive. A lengthy (often boring) 
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document does not easily convey a realistic sense of how the 
system will operate and suit the user's needs [Ref. 76]. 

Interpretive models include SADT and USE. These 
models use top-down decomposition to manage the comrpiexity 
cf large systems. The more detailed these tools are {or 
become), the moré specialized the language used. This pres- 
ents a significant learning burden to the user [Ref. 76]. 

Frotctypes, cn the cther hand, present a more real- 
istic view cf the system to the users. The users can easily 
relate their experience with the prototype COutiel = 
requirements. 


eeeeero Vcrifvethe Peasibiiity of Design 


When prototyres are used to verify the faasibility 
of a design, the designers and users are evaluating the 
internal design of the software {Ref. 75]. After the proto- 
type is developed, several aspects of the design could be 
evaluated: the prototype could be used to implement and 
evaluate certain design decisions; the prototype could be 
used to develop and test a production system; the efficiency 
cf the protctype could be ¢xamined; or the prototype could 
be developed on one machine, and the final system implie- 
mented cn the target (or production) machine, when it 
becomes available. 


3. Ie Create the Final Sy 


e 


£n 


Prototypes may bé used to create the final system. 
This means that part or all of the final version of the 
protctype may beccme part of the production systen 
fRef. 75}. Examples of this technigue might include data- 
base managenment system (DBMS) applications. For example, 
once created, “he prototype Might remain unchanged espe- 
Cially if the system efficiency is satisfactory. On the 


cther hand, critical (or perhaps all) of the system would be 
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recoded for efficiency, either in the DBMS language, ina 
host language, or in assembly language. 
F. PROTCTYPES ADDRESS THE ESSENTIAL DESIGN ELEMENTS 


1. Prototyping i 


tn 


a Symmetrical and Adaptable Process 


Frototypes explicitly address the symmetry and adap- 
tation necessary in software design. Naumann and Jenkins 
(Ref. 62] believe that prctotypes provide an appropriate 
response to changes inthe develcpment process (protlems to 
solve and available resources) as well as to changes in the 
envircnment. Bally, Brittan, and Wagner state that the 
prototype strategy is an admission of failure, an admission 
that there will be circumstances when we will be unable to 
develcp the right system on the first attempt [Ref. 68]. 
Earl's ccmment perhaps best expresses the overall idea of 
symmetry and adaptation: 


Bete SLCcO2ype SYSTEM -« « alows 4 See es ¢ d2s2qn by 
Giscovery as much as by prediction, where the unexpected 
results may be as Ss a are sae for design as the 
exvected. (emphasis added) [{Ref. 64 =: p. 166}. 


2. Erototyping !Tamest the Wicked 


In Chapter II wicked problems were described as 
problems where the information is confusing, where there ars 
_ Many clients with conflicting values, and where «he ramifi- 
caticns in the whcele System are thorougly confusing. 
Compare those characteristics to the experiences cf Asner 


and King: 


- « « «, the protctype approach works when users do not 
know their specific requirements, {where ] the 2affective- 
ness of any, on particular approach cannot be easii 
assessed without real-life experience, . . . { where 
tne system will be an integral Bea of the day-to-day 
activities of the Users. . .-. [Ref. 79 ¢ p. 304 
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wicked 


Ceveloping prototypes does more than reccgnize 
problems. The designers and users of TOLtecy pes 


explicitly acknowledge such things as: 


1. 


Wicked problems have no definitive solution--as Baily 
and others have stated, prototypes are an admission 
that more questions can be always asked and more 
information can be requested. 

Every formulaticn of the wicked oroblem corresfonds 
to the formulation of the solution (and vice 
versa)--there is an explicit understanding between 
the desinger and user about basic assumpticns that 
will be made when designing a prototype, especially 
the first version; the protcype strategy is designed 
<c ccpe with a fluid situation and fuzzy requirements 
(Ref. 68 }. 

Wicked pzrcblems have no stopping rule--desiqners and 
users realize that prototypes may be continually 
mcedified cr refined until some external limit (time, 
E=“OuTCesyeobEOdue:.On need, user Satisfacztion, etc.) 
is reached. 

Sclutions to wicked problems cannot be correct ofr 
false. They can oniy be good or bad--protctyping 
Cyplecs- yeececogntzes the notions of "technically" 
CQ@nrec. and “ssyenologically" correct. Users contin- 
ually ask for refinements untii they become satisfied 
(i.¢., where the system is technically and psycho- 
Moga Cal lV "Gorm beet). 

In solving wicked roblems there is no exhaustive 
yet. (Of adgzissable operations--prototypes aliow 
designers and users the freedom to explore and expéer- 
itent. 

No wicked proklem and no solution to it has a defini- 
tive test-- designers and users become quickly aware 


that prototypes clearly identify tzradeoffs. The 
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PrEetctype may ke flexible and sacrifice (i.a., "fail" 


the test for) efficiency. 


Ba selttware Protctyping is Satisficing 


bad 


Recall from Chapter II Simon's argument that peorle 
accept alternatives which are good enough, not because they 
want to, tut because they have no choice. in Chapees: Lire 
evidence was presented which cleariy shows that software 
designers ccnstantly balance trade-offs and are fcerced to 
accept satisfactcry alternatives, rather than an optimal 
alternative. 

The process cf developing a prototype explicitly 
deals with satisficing by recognizing the interacticn amcecng 
the user, designer, and systen. Conflicting goals and 
priorities are inevitable. Negotiation between «he designer 
and user will lead tc a satisfactory system. 

In the prototyping process, the désigner ccnstructs 
successive versions of the systen, compromising and 
resoiving confiicts retween the context (that iS, user needs 
and desires) and the form, as constrained by technolcgy an 
economics [Ref. 62 =: fF. 37}. 


4. Erototyping is Communicating 


= eanwass «a= no = ae eg 


The prototype facilitates communication between the 
designer and the users The basic model of the pretoype 
frocess shows that ccmmunication is a necessary e¢élement of 
the process. Without communication there is no pretctyre. 
Mason and Cary [Ref. 76] believe that prototyping overcomes 
the fundamental froblems of ccmmunication between users and 
designezs. Naumann and Jenkins [{Ref. 62] emphasize the 
roles participants have and believe Pictur rOtor ypang 
stresses the interactions between the user and the designer. 
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Farticipatior in scftware design can be painful 
[Ref. 64], yet : 


Users play nore active roles in ese a) en than is 
possible with traditional development methods. Users 
Set the develcpment pace by the time they spend using 
and evaluating the prototype. ae decide when the 
457° cf evaluation and refinement ends. Ref. 62 : p-. 


The prototype approach exploits the interaction 
ketween tke designer and user. Contrast this with the care- 


fully mcnitored interaction in the traditional approach. 


iS a Learning Aid 
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Several authcrs [Ref. 64, 68, 66] agree that the 
very purpcse of the frototyre is to allow the user tec learn 
about the system; e¢xperience with the system is the mest 
valuable product. When prototyping, both designers and 
users learn, develofing a system which is more realistic in 
its econcmic purpose, organizational context, and technical 
pertcrmance [Ref. 64 : p. 166]. 

Earl [{Ref. 64] believes that prototype systems 
permit acticn learning and that there are few other vehicles 
availakle fer live and flexible organizational development. 


As a vehicle for learning, 


[mes «) the proteyre model is the most effective terre- 
sentaticn fossible since it enables evaluation of «he 
prceposed design in context. The prototype model is the 
representation that anticipates avaluation of the design 
in its operating environment. [Ref. 62 : p. 33} 
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As pointed out in Chapter III, the organizaitonal 
context is an important consideration in systems ard soft- 
ware desicn. Informal organizational structures and the 
sub-ciements of organizations play large roles in the 
success cr failure cf a system. AS an e¢xperiment, the 
prototype prevides an opportunity to test the impact of 2 
syster and experiment cn the organization's interfaces, at 
least reducing the risk of a nonviable system and also 
Peevading Cpportunities for introducing and monitoring job 
satisfaction improvements, organization development, and the 
like [Ref. 64: p. 164}. Earl believes that prototypes are 
relevant to organizaticns because of individual differences 


among pecple in the crganization: 


- - - . the prototype methodology may be relevant, for 
Gpeterent velueées, perceptions and perspectives do exist 


ameng different interest groups, but the diiferent 
implicaticns and._impact of a system design may nct he 
BPereclated UNtTLL 1% LS implemented; indsed all the 
options may not be apparent. Aith a oor rototype 
system design values na be explicated ees ce ehcidéers 

Cee ST See ie sn 6 


counter the technical thrust of the specl 
fRef. 64 : p. ] 


To say that prototyping "“solves" the organizational 
issué€s in software design is, however, Gemmg .O6> faz. 
Prototyping deais explicitly with the issues, yet requires 
Meee a rit of "orchestration". The management cf the 


Erocess is not without political consequences [Ref. 66}. 


G 


cw do we méasure the worth of a prototype as it 
contributes to our design cf software? Earl answers this 
question with the following statement: 


32 rapes the mest valuable contribution of the prototype 
methcdclogy is to fester a climate of system Sg cea 
ticn, user Peasy and experimentation, intelligent 
use and organisaticnal learning. [Ref. 64 : p.j 166] 
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cess is Evolutionary 


That the precess of protoyping is incremental and 
evoluticnary shold ccme aS no surprise. The important point 
is that the prototyp¢ process, again, explicitly deals with 
the issue. Software design has been shown to be 2volu- 
tionary, yet traditional software development is unable to 
deal with it. Naumann and Jenkins [{Ref. 62] state, asa 
‘principle', that "[pJrototyping represents and parallels 
the dynamic process of growth, change, and evolution 
existing in any living system." 

A survey of the literature reveals an interesting 
pattern among the models fer prototyping. Aitnough most 
authers will agree that the traditional life cycle is not 
evolutionary, with the exception of Naumann and Jenkins 
{Ref. 62], (see also figure 4.1) Basili {Ref. 65], Bally and 
cthers [Ref. 68], Earl {Ref. 64), Mason and Carsy [{Ref. 76], 
age Zvegqintzov {Ref. 57} all attempt tc force a cyclic 
Structure on software development. 

Ferhaps a review of evolution is in order. When 
some thing (animal, crganizaiton, or design) evoives, it 
begins simply (a few cells, a few people, a few details and 
Many Simplifying assumptions) and grows in complexizty, cften 
Changing remarkably from its humble beginnings. This 
process is clearly net cyclic. Rather, a better image is 
mie spiral, much like the spiral coil of the shell of the 
Nautilus, growing in size yet maintaining the essential 
nature it began with. 

Figure 4.2 illustrates the evolutionary nature of 
prototypes. Each "chamber" can be considered to be a single 
prototype, the wall cf the "chamber" denoting the foint of 
refinement and enhancement. The only restrictions on the 
number of “chambers" (prototypes) are in the envircnment 
(exhausted resources, end of time, too complex or unwieldy, 


and sc cn). 
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Figure 4.2 Evolution of Prototypes. 


Ge. SUMMABY AND INTERMEDIATE CONCLUSZTONS 


This chapter has explored the multi-faceted aspect of 
the software prototyre: the process, its role as a nedel, 
constructicn strategies, and uses. The chapter concludes 
with a persuasive argument that prototypes explicitly 


Support the seven design elements. 


Oe. 





ct 


Several conclusicns can be stated at this time. Hos et 
the current practice cf software engineering only recognizes 
fmmecw ct the design elements described in Chapter Il. 
Software design completely ignores the ‘fact that these 
elements are interrelated and mutually dependent. The 
traditicnal methed of software development only worsens the 
problen. 

Second, «che prototype approach to software design and 
develcpment naturally suppcerts the set of design elements. 
For example, the pretotype approach énccurages, requires, 
and expleits the interacticn and communication bétween the 
user and designer. Ey making this explicit, prototypes wiil 
lead to a ketter design. 

Third, developing better systems, delivering them on 
time and within budgets are in our best interests. The 
protctyrpe approach will allow software engineers and 
designers tc achieve these goals. 

The next chapter triefly describes software Engineering 
envirenments and how suck an environment could and shouid 


emeoort scftwate pretctyping. 
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V. THE SOFTWARE ENGINEERING ENVIRONMEN 


Ae INTROCUCTION 


Most authors agree that prototyping has become possible 
through recent develcrpments in computer technoiogy [Ref. 61, 
62}. Ccllectively, this technology is called the software 
engineering environment (SE?) [{Ref. 83], the programming 
support environment [Ref. 107, 105], or «he software devel- 
opment environment [ Ref. 84 }. 

There are as many definitions for, as there are 
references to, a scitware engineering environment. The 
definition cffered by Hausen and Muellerburg seems te be the 


most satisfying: 


(A Software Engineering Environment is ] an instrumented 
and organized software development iaboratory where many 
pecrle cccperate with each other ina fully organized 
WOTKLad orocess, in the désign, construction, examina- 
1097. eUne ng anda W@drneoenaace OF SOftware. [Reft. 83 : Pp. 


Generally soveaking, the literature cites two arfroaches 
to cemputer-aided design for software development: 1) the 
SE? is a systamatic approach, and 2) toolboxes or toolkits 
Merch Suppcrt specific software davelopment activities 
{Ref. 85}. the UNIX development environment is an excellent 
example cf *he tcolkit appreach [{Ref. 86]. The facilities 
Of UNIX may be thought of as a "tool kit" from which the 
develceper can select tools shat are aporopriate fer a 
specific task. Detailed discussions of the UNIX environment 
and available tools can be found in [{[Ref. 87 , 88]. 

ihe  ocikit aporcach, howévser, has been criticized 
because: 
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ile LOO1S are not crganized to support specific sofware 
develcpment methodclcgies; 

2. fccels do not capture management or control data for 
scftware development; and, 

3. Individual tocls are largely uncoordinated [{Ref. 89]. 

Lauber has reviewed 11 tool systems in practical use and 

finds that cnly two systems (PSL/PSA and PDL) are in wide 


use, 3 


There are several "programming" environments in active 
use (for example, Interlisp [Ref. 90 , S647 9 1). eos 
planned (for example, the Ada programming support envircn- 
ment (APSE) [Ref. 93]). Unfortunately, there is ne SE@ 
which specifically supports the prototype precess. Ts 
Chapter will first describe some general characteristics of 
SE2?s and then explain those elements of SEZ@s which are 
needed to support software design and prototyping. 


PB. CHARACTERISTICS CF SOFTWARE ENGINEERING ENVIRONMENTS 


Theré¢ is general agreement that an SE2 supforts 
three develcpment "tasks": 1) software production manage- 
ment, 2) t¢chnical aspects of software development, and 3) 
user participaticn in applications development [Ref. 83, 94 
me 2 |. An SE® aids software management by “carpturing" 
information about design decisions and the progress of the 
develcrment itself. An SE2 supports software develcpment by 
providing automated tools. During the developmen= of 
eeecific applications, the SE? places special emphasis on 


the rele cf user-designer interaction. 


S8EFroblem Statement Language/Problem Statement Analyzer 
and. Fregram Design Language. A detailed review of the 
various tcols and @nvironménts in current uss can be found 
ah, 2YRECSiUN on software Engineering Environments , dHuenke, 
edltor. 
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2. Integrated - 


An integrated SE* will support the three develorment 
tasks by unifying the tasks into an ensemble. Integration 
applies to the ease of using and the ease of documenting 
those activities asscciated with individual tools [Ref. 84]. 
Perhars cne of the mcre important characteristics of an SE2, 
integration makes it easier to combine various tcols in 
Seager to perform a specific function. 


eee Ona tcr nm 


A variety of automated tools are used by the SE2 to surport 
the three develorment tasks. For reliable operaticn, the 
tools must be consistent with one another {Ref. 84, 94 , 95 
m6 je If one tool is consistent with the rest, the SE2 
will be easier to tse. It 1S easier *o learn and use 
special fcrmats and ccmmand structures when they are consis- 


tent among éll of the tools. 


4. SuEECre & Solution Stratedy 


The technical aspects of software developmen: 
require the SE2 to support two solution strategies, ene 
general and the cther specific. Generally, Soni and others 


believe that the SE2 must support different ways of solving 
the froblen. (Ref. 84]. That is, the SE@ should support 
Many different ways cf solving problems. It should be fiex- 
ible encugh any rfroblem-solving strategy. For the specific 
strategy, Wasserman andothers believe that an SE2 must 
support both the software life cycle model (the ‘waterfall’ 
model) and any particular software development methodolccy 
which dees not diverge very much from that model [Ref. 94, 
eo oT je. In either case, the objective is the same: to 


arrive at a solution. 
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5. Adaptable 


For practical reasons, an SE2 should be adaptable. 
In most organizations, each of the development tasks is 
covered by different crganizational groups, each with their 
Own styles, attitudes, and so on. Also, the individuals 
within ¢ach group bring different perspectives to the jcb. 
With such awide range of personalities, a collecticn of 
toois shculd be flexible, changeable, even extensible 
(Ref. 84}. The SE2 should be able to adapt to the design- 
er's (or user's) sophistication and should provide defaults. 
Defaults cculd be ¢asily changed as users become more 
scphisticated [Ref. 94, 95, 96]. 


6. Functionally Unigue 


= =p as [= 


Within each development task, there are a number of 
unigue functions. Ic réduce ambiguity, misunderstanding, 
and €rrors, to0ls within an SE2 must be functionally unique. 
That is, they must have a singular purpose {Ref. 84, 94, 95, 


Same Each tcol must te limited to a single design fEuncticn. 


7. j%$Interactive 


An SE2 must havé¢ interactive system capabilitics. 
[Ref. 85, 84, 94, 95, 98}. There are two reasons fer this: 
interactive systems aid communication among tne participants 
in design, and designers can work at their own pace (inter- 
actively) rather than someone else's (batch). User partici- 
paticn, cne of the development tasks, 1s simplified when 


using interactive systems. 


8. Recent Develcrments 
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Two ideas abcut SEZs, personal development systems 
and a software engineering knowledge base, seem to unify the 
three develcpment tasks and embody the characteristics just 
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Stated. Personal development systems have all of the char- 
acteristics discussed (integrated, uniform, support a solu- 
tion strategy, adaptable, PUuneCtTIONaL ly unique, and 
interactive). Their most important feature, though, is the 
dedicated support to a single designer [{Ref. 89 , 94 , 95}. 
A software ¢envircament knowledge base would capture informa- 
tion abcut the design activity (for example, design deci- 
sions) as well as the development process (a continucus 
effort) fcr managers, designers, and users [Ref. 96]. This 
knowledge base would make the information easily available 
and wculd b= done autcmatically. 


C. A SOFTWARE ENGINEERING ENVIRONMENT FOR PROTOTYPES 


Mest authors agree that a ‘successful’ SE* must suppecrt 
a certain view of the design process [Ref. 85, 94, 95, 97}. 
Following the lead of Lauber [{Ref. 85], a ecOULECticn -of 
toois, or components, which support the set of seven design 
ememMments Of Chapters II and III, and which suppert the 
dévelerment of protctyves, covered in Chapter IV, is 
presented. This is followed by descriptions of how such 
compcnents suppert scftware design principles and proto- 


myo 1d. 


1. Technical Corfonents 


There are several components which sheuld be 
included in an Ske (Ref. 62, 75, 79, 83, 101). 


a. Database Management Systems (DBMS) 


A DBMS serves two purposes in an SE®. Patesce, 
the DEMS enables storing and retrieving informaticn abcut 
the design as well as the development process. For example, 
a reccrd cculd be kert of when each version of the protctype 


was released, who designed it, relevant design decisions, 
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and so on. Seconds se DaMsS allows £0r ‘"gquick* design and 
programing of data handling features [{Ref. 62, 61, 83]. 
Recail that the ability for quick turnaround of a werking 
system tc the user is a necessary feature in many proto- 
typing situations. 


bk. Generalized Input and Output Software 


Query languages, report generators, and report 
writers are often features of a DBMS (for example, FCCUS, 
RAMIS II, and NOMAD frovide these features). These features 
allow fer easy data retrieval and data update. Repcrt 
generators can produce compiicated reports with minimal 
programming effort [{Ref. 61, 62, 79, 101}. 


¢c. Graphics Tocls 


Graphics are ideal for representing the large, 


and cfiten compilex, Structures of non-trivial software 
designs. These tools are particularly suited for the recth- 
odolcgies which use structure charts. For exampl2, Delisle 


Mme. 102) cescribes a set cf graphics-based tocls, an Edit 
tool, an Evaluate tocl, a Format tool, anda Clean-up tocl, 


which were develcped to support Structured Analysis). 
d. High-level Languages 


High-levei languages (variously described as 
non-procedural languages, fermal specification languages, 
and so on) have one objective, flexibility [Ref. 62, 83, 
101]. Such languages enable the designer to describe" what 
to do" rather than "hcew to do" it. The system resolves the 
procedure and snculd produce executable machine code. The 
designer, given such a tool, Can use abstraction to its 
fullest extent (th¢ Gamma software engineering system 
{[Ref. 103}, for example, specifically supports abstraction). 
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€. Interactive Systems 


Devices and equipment (for example, working 
staticns) which suprert interaction are essential { Ref. 61, 
62, 83, 98]. Interactive terminals give users and désigners 
the perception of rapid and efficient operation and revi- 
Sion. Generally, these facilities are adapted from the hcest 
computer ornetwork of the SEé. (Personal develorment 
systems cculd be thcught of as extensions of interactive 


systems.) 
f. Applicaticn-oriented Models 


Models are an lmportarnt feature of an SE2. They 
acre used to support human decision making [Ref. 61, 62]. 
Examples of models which are potentially useful are finan- 
cial rodelse (as in FOCUS) or simulation models. Real-world 


modelling { Ref. 43] is also an important element in the SE. 
aq. Tools fer Software Testing 


tome oweveca=a ly a need for tects which sizrlitr 


< 


software testing [Ref. 83, 101]. Hausen and Muellerburg 
report that most tools of this type concentrate? on verifica- 
tion and validation, that is convincing ourselves thaz «he 
program will exécute voroperly. They argue that scrttware 
tools fcr pregram testing should cover more than just veri- 
meeation and validation. They recommend a philosophy of 
quality improvement which includes quality assurance 
(definiag software standards and controlling their cbserva- 


ct 


tion), acceptance testing (demonstrating to the user that 
the scftware 1s accertable for operation), and verification 


and validaticn. 
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2. sugrort for Scfitware Design 





Any SE? must fe based on a particular view cf soft- 
ware design. [{Ref. €5, 94, 95, 97]. The view presented in 
Chapters II and III is unique, although elements of that 
view may be supported in different ways by different 
systems. 

The SE2 must recognize, and provide facilities for, 
the symmetrical and adaptakle process of design. If the 
soluticn tc a problem changes the problem, features cf the 
SE2 must allow revisicn, interactive use by clients (i% is 
their problem, after all), and record-keeping, especially of 
decisions.? 


fhe satisficing aspect of design may best ke met by 


uSing the modelling tools of the SE2. Simulatior tcols can 
help answer "what if" and performance questions. Financial 
models can help decide economic questions. Planning, 


contrcl, and estimating models can also helo tc decide on 
fameewerth of various tradeotfs. 

The "wicked problem" aspect is particularly vexing 
Se che SsEe@. High-lével Languages can help by allowing an 
abstract description as a formulation of the problem. The 
abstract statements are then transformed by the system into 
concrete (that is, executable) code { Ref. 105, 106, 107]. 

Communications between the user and the désigner is 
aided by interactive systems. Graphics aiso aid user (and 
designer) comprehension. Alexander and others have shcewn 
how the notion of patterns helps bridge the communication 
Gap . Kuc, and cthers, [{Ref. 80, 84, 108, 109, 110, 11147 
have aderpted this cencept in their "“forms-based" software 


development environment. The ‘forms! within the system are 


9White [Ref. vue, presents a modei for recording relé- 
vant information aEout design decisions during software 
develcement. 
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used tc identify and define ‘'patterns' that are akoveée the 
level of precgramming language constructs. Although a full 
discussicn cf *he TRIAD (TRee-based Information Analyzer and 
Develcper) system is teyond the scope of this work, it is an 
excellent candidate for an SE2 which supports software 
Prototyping. 

The interactive facilities and modelling features of 
the SEF2 will help teaid the learning process in design. 
The notion of ‘learning by doing! was introduced in Chapter 
feed . DecamcUbpPpOre cthdt) nOtion, the SE2 should aliow the 
designer to learn, 2arly, the consequences of a design deci- 
Sion. The desiaqner must then be given the chance to revise 
his décisicn, based cn the ‘operation’ experience. 

Crganizational issues must be explicitly recognized 
in ary SE2. First, there are organizational resources which 


are needed to support the SE@2: programmers, operators, 
managers, space and facilities, and the computer hardware 
assocatéed with the SEée. Second, the work patterns and work 


Serric cf the voeopnle who work in the SE2 are likely «+o 
change. Unfortunately, mcst current development envircn- 
ments stress the environment over the users of the enviren- 
men+ [Ref. 98}. Typically, those environments have "quirks" 
which reguire people to adjust. The system should adjust to 
the skills and the preferences of the designers who use it 
(using, fer example, custcm default features). It we 
consider the SE2 as an slement of a compiex organization 
(Ref. 59, 60, 98], the environment's interaction with people 
is crucial; without that interaction, the SE* is useless in 


any practical sense. 


iD 


Finally, tre SE2 must explicitly recognize th 
evoluticnary aspect of software design. The current systems 
support the waterfall model of software development 
(Ref. S4, 95}. The database management system, interactive 


facilities, and high-level languages will easiiy supfert the 
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evoluticnary concept of design. Report generatcrs and 
report writers should aid the documentation process as thé 
design evolves. 
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The process cf developing a software prototype was 
covered in Chapter IV. There are four steps in that 
process: 1) identifying the user's basic requirements, 2) 
developing a working prototype, 3) igplementing and using 
the protctype, and 4) revising and enhancing the prototype. 

An €xisting database of the SE? is ideal for idénti- 


fiying the user's initial requirements. Hcwever, there are 
rroblems if the database is empty. Kangasallo {Ref. 112] 
preserts a model in which information réquirements are 


interpreted as a set of complex queries by the database 
management systen. Additional features cf that mcdel 
include a ‘'rrogram ccnstructor' which generates code kased 
on the queries. A working prototype is a result of this 
model. 

Another methcd depends not only onthe databass 
Management system but also cn the automated tools within the 
SE@. Cheatham [{Ref. 105] presents a system in which the 
designer and user develop an abstract model of the preblen 
(possibly frem the database). Transformation refinement is 
applied (by the automated tools) which results in executatrle 
meage--a working crotctype. 

In both of these instances, the SE2 supports the 
develcpment cf the user's basic requirments followed cy an 
automated process of developing a working prototype. 10ic  S 
important that some effort be made? to analyze che user's 
requirements so that reasonable queries can be made ard 


reascnable models (of the problem) can be developed. 
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Other systems are available which help to develop a 
kasic sét cf user requirements. Some ara guite compl=x 
(Ref. 32] ard might be difficult to integrate with the SE2. 

Developing a working prototype, quickly, should not 
be difficult to accomplish in the SE2. High-jevel 
languages; code generators; transformation refinement 
(mentioned above); application development systems, such as 
ACT/1 [Ref. 76] and, application generators [Ref. 75] make 
it s¢asier to develcp working prototypes. Ideally, the 
system wculd be completely automated. 

An abstract model allows the designer to focus mcre 
eaSily cn the results of his or her decisions, rather than 
the implementation details. An abstract model also premotes 
flexibility when it is reused. [{Ref. 105] 

Ioplementing and using the prototype becomes much 
easier wren interactive systems are used. User interaction 
is essential and interactive *t¢rminals allow the user to 
Beeceive rapid Oferation and revision. TASyea.sc  Relpor}] 
spesd us¢z evaluation [Ref. 62}. 

Revision and enhancement are facilitated in the SE2 
by using the database management systea, high-level 
languages (and abstract models), the generalized input and 
output tcols, and graphics tools. The database contains 2 
record cf fast designs and design decisions, changes are 
easily made to abstract models and high-level language 
Senstructs, default values of the generalized input and 
output tocls are easily adjusted, and the graphics tocls 
will enakle both users and designers to spot patterns 
quickly. The user is quickly accommodated, the database 
Management system automatically tracks versions and design 
decisions, and the designer is able to defer low-pricrity 
details without fear of compromising the design: the SE2 
relieves the designer of much, if not all, of the drudgery 
normally associated with software design. 
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D. SUMMARY 


The preceding sections have reviewed the characteristics 
needed ina software engineering environment, have identi- 
fied the components of a software engineering environment, 
and have described hcw the components interrelate to support 
both software design and the prototyp2 process. 

It is dcubtful that there are any software engineering 
environments which support completely the idéa cf proto- 
iy DiC. Tc a limited degree, commercial systems, such as 
FOCUS, NCMAD, ACT? Ile to name a few, support particular 
aspects cf the prototype process. For example, FCCUS and 
NOMAD facilitate applications programming inthe business 
community by allewing the designer to customize reports or 
other appplications for a specific user, or group, based on 
an alréady existing database--the vice-president of sales 
might ke interested in the sales of a particular prcduct in 
a particular geographical area. REV/ 1) Panag ot ner similar 
products, make it é€asier for designezs to custemize the 
formats cf *erminai screens for the user. 

The products nentioned here ar2 three of several hundred 
commercial and research systems and environments. This 
Chapter has purfosely avoided a lengthy review of any of 


those hundreds, and mentions a few by way of example oniy. 
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VI. CASE EXAMPLES 
The four cases which follow were chosen because in each 
there was an explicit decision began to develop and use 
software prototypes before the project began. 


Aw. SYMMETRY, EVOLUTICN, SATISFICING, AND COMMUNICATION 


Heckel [{Ref. 113] describes the process of developing a 
ptototype while designing the Craig translator. The preject 
¢+eam explicitly chose to develop prototypes for several 
reascns. ipabo sins they were concerned about the proktlems 
which users would actually experience, rather than these 
problems which the designers imagined might be important. 
This ccencern is directly related zo 6 the «symmetry aspect in 
design. That is, tke solution and problem interrelate such 
that the solution derends critically upon the context of th 


‘p 


problem. In this case, the context is the consumer's use of 
the Translator. If the product does net perform as 
Nexpected", it will net sell. 

Second, the project téam was interested in postpcning 
decisions about restraints on the final system until «hey 
maa to. in Soures words, their design evolved. The 
designers ignored certain restrictions which had been placed 
on memory size, as long as they carefully considered the 
effects of their decisions on the production version of the 
Translatcr. 

Third, the project team planned to use the prototyre as 
the scftware specification. Because they had two "versions" 
of the prototype, a black box translator and the pregzran 
listing, they thought that they would avoid the traditional 


misunderstandings and contradictions often found in written 
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software specificaticns. In this case, the designers were 
concerned akout communications, not only between the "user" 
and the "designer" but also among themselves. 

Heckel's déscripticn shows that the prototypes (there 
were 30 versions!) were used to clarify requirements and to 
verify tke feasibility of the design. Heckel states that if 
they had been forced to make a particular design déecision 
earlier than they did, they probably would have made a less 
satisfactcry decision. 

The project was judged a success, although frogress 
seemed slew and painfvl. Heckel identifies four benefits of 
developing prototypes: 

1. The project team could keep trying new things; 

2. The prototype was a good model of the final preduct, 
sc everyone had similar expectations about what the 
product would do; 

3. Several decisions could be post poned without 
affecting the schedule; and, 

4. Tre designers focused their efforts on opvortunities 
rather than problems. 

The development process had some disappointments: seft- 
ware development tock longer than expected and the final 
product tcck more memory than expected. Heckel did not 
speculate on whether these "disappointments" could have been 
avoided. One interpretation is that the designers were 
unable tec meet all of their objectives and when time ran out 
their design was judged to be good enough. PAS, the 
"disappoirtments" can be attributed to the satisficing 
aspect of design, especially the need for more memory. The 
designers obviously made a trade-off between the “gocdness" 
cf the preduct and the amount of memory they had originally 
planned. 
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Bo. LEARNING 


Hemenway and McCusker f{ Ref. 116] describe an exploratory 
project which is leading to the development of an crdar 
negotiaticn and entry support system for telephone sezvic 


10) 


(the Bell system). The project is the development cf the 
user interface and the supperting software for the svsten. 

There are two reasons given for buiiding an oferational 
Beecctyre: 1) to evaluate the user interface anc 2) to 
assess the feasibility of a particular sortware architéc- 
eure. Even thcugh the reasons coincide with two usés of 
prototypes (that is, *o clarify user requirements and to 
verify the feasibility of a design) they are related <c two 
aspects ci design. The aspects are learning and ccmmunica- 
+ion ketween the déesianer and user. 

Proztctyres of the software were daveloped to determine 
whether a table-driven system could be designed. Prototyres 
cf the user-interface were used to determine whether the 
user-interface wculd substantially increase the length of 
time servicé representatives spend on orders (compared to 
Manual cxrder entry ard search). 

The case concludés by stating that the results of the 
prototype evaluation led to making severai recommendaticns 
to the designers of the first release of the system. Hence, 
the protctype served to help he designers learn more abeut 


their scluticn and their problan. 





C. WICKED FROBLEMS, CCMMUNICATIONS, AND THE ORGANIZATIONAL 
COCNTERT 


Jenkins [Ref. 114] discusses how the decision tc develop 
a prototype led to successful development of an automated 
data precessing facility for the Congressional Budget 
Crt iceé. 

Two aspects of seftware design are apparent in this 
case: 1) Communications between users and designers and 2) 
the organizational ccntext of the system. Communications 
ketween the designers and users was greatly improved by 
using a prototype. Rather than try to decide on the design- 
ex's effectiveness Ey reviewing writt2n specifications, 
Managers witnessed operating demcnstrations. The protctype 
@€iso shewéed non-technical users what it was possible to do 
in their application areas with the new tools. 

By far the most important aspect illustrated by «his 
cas@, is vehe cencern of the designers for organizational 
issues. The Congressional Budget Jffice serves the needs of 
the Cecngréss, admittediy a complex crganizacion. Se 
designers needed immediate responses to Congressi 
inguiries, because when information is needed, it 
needed immediately or its valu? is lost. 

This organizational aspect is also closely rel 
wicked froblems. Recall that wicked problems re 
social system problems which are illi-formulated, where 
informaticn is confusing, where there are many clients and 


decision-makers with conflicting values, and wher: the 
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FaMifications in the whole system are thoroughly cecnfusin 
Clearly Congress is faced with these kinds of frroblems. 
There is every reason to expect that the Congressional 
Budget Cffice deals with similar problems when responding to 
Congressicnal inquiries. 10 





The case presented by Jenkins illustrates how protetyres 
Can aid scftware design when faced with critical corganiza- 
tional issues and wicked problems. 


D. COMSUNICATION, LEARNING, AND EVOLUTION 


Groner and others [Ref. 115] present a case cf using 
prototypes to clarify the user's requirements. The case is 
unusual because it started with a proposal frem outside the 
user's ccmmunity. The designers set out toc determine if and 
how ccmputer technelogy could meet the Dereon dat On 
processing needs of médical researchers. 

This case is a clear illustration of the importance of 
communicaticns between the designer and the user and the 


representation used fcr communicating. 


eae TESS were required in the requirements analysis 
phase Eécaus= withcut concrete, working examples our 
potential users could not be sures *hat computer systems 
are needed, what functions they should perform, cr how 
they weuld use them. [Ref. 115 : p.j 100] 


Less clearly stated is the implication of Ilearning 
during the design recess. The intitial desiaqn of the 
prototype was based on the designer's knowledge about 


_!0Consider the fluctuations from Congress to Ccngress, 
Chairman to chairman, committse to committee; from yaar to 
ear, week to week, and even from hour to hour during the 


sudget Ccmmittse markup sessions [Ref. 114 : p. 22]. 
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informaticn processing needs fOr medical res¢arch. 
Subsequent versions were improved based on use by and 
comments frem clinical researchers. The project partici- 
pants 


© « .e ,agreed to learn about each other's disciplines, 
then define preblems and attempt to devise and evaluate 
solutions in collaboration with others inthe taraet 
user ccomunity. [Ref. 115 : p. 


The project used an incremental implementation strategy 
(evcluticn) under which major software releases ware sched- 
uled approximately every four months. Several hundred soft- 
ware changes were made over a period of a year and half. 
This case shows how prototypes can be used +o create the 
inal systen.!! 











E. SUMMARY 


These cases illustrate how prototypes helo designers 


cope with the seven aspects of design which were covered in 


Saapters if and III. In each of the cases, the authors 
point to success. For deckel, the prototypes led toa 
Froduct that was easy +o use, had a number of usetrul 


features, and waS implemented ona sSingle-chip micropro- 


CeSsot. 


1i1The case description leads the. reader te *hink that.a 
"Oroduction" system was not developed. Every indicaticn 1s 
that the prototypes evolved into tne production system. 
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Hemenway and McCusker say only that prototype evaluation 
led to reccommendations to the designers. Foolvcn.ss, we Can 


safely infer that the prototype aided the designer's under- 


f) 


standing of the froblen. 

For Jenkins, the cverall assessment to the prototypé¢ was 
positive. Managers liked the idea of a prototype because 
there was ne prior commitment +o a particular course of 
q@eerion. 

Groner and others believe that the greatest benefit of 
the protctvpe is that the fprotctypes are concrete, working 
examples cf computer systems which are meeting everyday 
needs. 
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VII. CONCLUSIONS 

A néw view of design was presented in Chapter II. This 
view identifies a set of seven interrelated and mutually 
dependent elements which were found in the literature. 
Support for these elements was found throughout the computer 
and information science literature. The set of seven 
elements explains how best to cope with the problems, amti- 
guity, and uncertainty associated with scftware design. 

The precess of developing a software prototype is 
presented as the most appropriate way to incorporate the 
design elements into software design. in face, one Pro to- 
type precess exploits certain elements, such as ccmmunica- 
tion ketween the user and designer, to improve the overall 
design cf the software. 

Cneé of the more important conclusions is *hat software 
designers, especially designers of large-scale systems, have 
much to learn from designers ia other fields. The software 
design literature shews little evidenc2 of influence from 
Other design fields. This werk is a start toward that 
needed transfer c£ kncwledge. 

The software prototype may be the sensible way te design 
large-scale systems. Recall that complex design prektlemse 
have been called wicked problems. If sone large-scale 
System deéevelopmants are ‘more wicked’ than others, +hen 
developing prototypes seems to be the only way to design the 
SySten. 

Software prototyping enables users and designers +o cope 
With ill-defined problems and changing requirements. Past 
experience indicates that bad technical engineering is nota 
problem with sortware development. Ratner, unsatisfactory 


design decisions and faulty information are the real 
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problems. Software prototypes provide a mechanism which 


allows designers to test their decisions and to il 


(b) 
1 
4 


cn mere 
aoeur =e rroblem. The prototypes also allow Sere a 
construcyive environment in which to axpress th 
muon Cr dicsatisfacticn anda stimuitant in learnin 
deal with their problems. 

Software prototyres, however, presen*+ special difficul- 
ties kecausé they are not the universal remedy for scftware 
design problems. Careful management is ne2ded to ensure che 
Se@moware ptototype is really designed and net just fut 


tegether. Careful theught and olanning are necessary betcre 


coding begins. Manac4rs, d¢sSsigners, and users must remember 

that a scftwars protctype 1s an experiment. Judgement and 

commitment are needed tc control Seaiess sits sa tions. 

Managers must have the wisdom tc know when to stcop. Ore en, 

While develcping successive prototypes, there is a tendenc 
= 


sO délay fcermally documenting the syst 
BeoolLeMm 1S not unique te pretoty = 
Menegemen+ and commitment =o ensure adecu 


@eenumenta*icn. 


fmm SeELte OF these cautions, evidence indicates that 
develcpina and using scftware prototypes is the best 
u 


Y 
Mee CCping with software design problems, for ean 
u 


t ty 


Cz ele 


system is délivered, aad 


Bepulaticn. 
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A. MANAGEMENT 


Develcping scftware prototypes presents management with 
some unusual problems. Many of our current management tech- 
niques depend on getting the project done right the first 
time (Ref. 117}. As we are well aware, this seldom occurs. 
Research is needed to assess the effect of prototype devei- 
cpment cn management. 

1. How does the manager decide when to cease developmen+ 
of prototypes? When is the project ended? 

2. Hew dc managers deal with increased communications 
between users and designers? If special maragement 
ccntrols are needed, how far should they go? 

3. What management styl¢ best suits managers of software 
BEGecety De PEO JECtS? 

4. How is the preject budgeted and ccoatrolied? aca is 


crregress meastred? 


B. ACQUISITION AND CONTRACT MANAGEMENT 


Current acquisiticn and contract management procedures 
and regulations for software appear to be less than satis- 
factory, within the Federal Government generaliy, anc the 
Department of Defense particularly. Even as ‘*hese proce- 
dur2s and regulations are changing, there is some ¢vidence 
that the traditional model of software development may 
kecome required. The Department of Defense has tegun te 
address the concept of software prototypes in the DOD 
Software Technology Initiatives [Ref. DoD81 : p. 69-71], but 
this research appears to be concerned only with requirements 


specifications. 
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ieeicwmrcanweGr now  snould acguititicn and contract 
Management prcecedures and regulations accomedaté tae 
principles of design and software prototyves? 

2. What is the best strategy for encouraging acceptance 
of the software design principles and software proto- 
=ypes?: 

3. How might the elements of software design and devel-~ 
oping software prototypes help with «he acquisition 
and contract management for embedded computer 


resources? 


C. ORGANIZATIONAL CCNTEXT 


Kling and Scacchi [Ref. 59, 60] reviewed a large number 
cf organizational studies while developing their views about 
the effect of ccmputer systems upon orgénizations. When 
their ideas are considered within the context of software 
prototypes, further research is needed. 

1. How will chances in theories of organizational devel- 
opment affect the process of developing prototyoss? 

2. Is any one crganizational theory best suited for 
ecftware design and software prototypes? 

3. What are the social dynamics of software design? 

4, What are the social dynamics of developing software 


protctypes? 


D. QUALITY 


A fundamental part cf design is +o satisfy the needs for 
quality. Rooke {Ref. Rook82] has concluded that design is 
the mest important factor in determining overall quality. 
Even though one of the objectives of developing software 
prototypes is to achieve user satisfaction (a major element 
cf quaiity), research is needed to determine how prototypes 


can affect software quality. 
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1. If we accept that prototypes will affect a cnange in 


scftware technology, how will that change influence 
our percepticns of quality? That is, will software 


pretctypes lead users to expect more than can be mex? 


2. How might the concept of Quality Circles fit the 


precess of developing software prototypes? 


3. To what extent will software prototypes influence 


scftware quality? Since prototyping requires 
concensus, who is ultimately responsible for preduct 
quality and liability? Should anyone be "ultimately" 


respensible? 


REPRESENTATION 


The software prototype is the ultimate representaticn of 


} 


usexr's requirements. The written specification anchers 


other end of the representations scale. 


1. What other types of representations can aid software 


design and the development of software prototypes? 


De Wide Mek Neds sare Stuctable¢ for representing abstrac- 


ticns when identifying a user's a eee before 
developing a scftware prototype? 


3. Hew de different representations affect our percep- 
tions and sréal world knowledge? Can differen 
initial representations lead to quicker design and 


development cf software prototypes? 
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